Extended Web Enabled Multi-Featured Business To Business Computer System For Rental Vehicle Services

ABSTRACT

A method and apparatus are disclosed for use in connection with managing rental vehicle reservations where different parties can be empowered to perform various management actions on the reservations. In this way, the workload with respect to reservation management can be spread over multiple parties. In a disclosed embodiment, the different parties can be parties such as insurance companies, repair facilities, assist companies, credit hire companies, lawyers, and fleet management companies.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional of Ser. No. 10/343,576, filed Jan. 31,2003, now U.S. Pat. No. ______, which is a national stage entry of PCTSerial No. PCT/US01/51437 filed Oct. 19, 2001, the entire disclosure ofwhich is incorporated herein by reference.

This application is a continuation-in-part of Ser. No. 13/025,617, filedFeb. 11, 2011, which is a continuation of Ser. No. 09/694,050 filed Oct.20, 2000, now U.S. Pat. No. 7,899,690, which is a continuation-in-partof Ser. No. 09/641,820, filed Aug. 18, 2000, now U.S. Pat. No.7,275,038.

REFERENCE TO A COMPUTER PROGRAM LISTING APPENDIX SUBMITTED ON COMPACTDISC

This application includes a computer program listing appendix submittedon a compact disc, the compact disc containing the files “Exhibit A.txt”(file created Dec. 28, 2010; file size of 316 kilobytes), “ExhibitC.txt” (file created Dec. 28, 2010; file size of 534 kilobytes), and“Exhibit D.txt” (file created Dec. 28, 2010; file size of 262kilobytes), these files being incorporated herein by reference.

INTRODUCTION

The invention disclosed and claimed in the first filed parent crossreferenced above relates generally to the field of an Internet enabledbusiness-to-business intelligent communication link allowing a firstbusiness organization to have intelligent interaction with a secondfully integrated business organization to facilitate the placing oforders or reservations for business services or goods, with the servicesor goods provider having a computer network linking multiple levels ofits organization to provide for the smooth conduct of business betweenthe two organizations. More particularly, this field relates to anInternet enabled automatic rental vehicle transaction system tofacilitate the conduct of rental vehicle transactions between twomultilevel business organizations, one of which provides such rentalvehicle transaction services in an integrated manner through businessenterprise software to a high volume user of such rental vehicleservices wherein an Internet web portal is defined by the rental vehicleservice provider which interconnects the two business organizations atmultiple levels, providing a graphical user interface (GUI) for thetransaction of large amounts of rental vehicle services automaticallyand virtually without human intervention upon entry. The invention ofthe second filed parent continuation-in-part application extends thefunctionality of the first filed parent invention by providing anintelligent portal that is readily configurable to suit any particularcustomer and any particular provider data requirements or method ofdoing business. This added functionality allows the invention, forexample, to provide the user with access to other suppliers in the sameseamless and integrated manner. In other words, the user now has accessto not just one integrated business but multiple businesses, some ofwhich may but need not be, integrated businesses thereby extending theinvention for use in a generic application to satisfy a users needs fora good or service not just from one vendor but all vendors connected tothe invention. The inventions disclosed in this application add to thefunctionality of the systems first disclosed in the two parentapplications by providing features and advantages which increases itsflexibility and adaptability to other business models as might be foundin different countries for handling rental vehicle transactions.

BACKGROUND OF THE INVENTION

Computer technology has been embraced by many businesses in order tohandle their ever increasing order flow as well as to mitigate theincreasing blizzard of paper required to be produced to document thisbusiness. A significant benefit which often drives the implementation oftechnology is its further advantage in increasing productivity tothereby allow fewer people to handle greater volumes of business. Onesuch good example demonstrating the efficiencies and value to be gainedby implementing technology is the business model developed and followedby the assignee of the present invention. A rental car company at itsheart, the assignee transacts an ever increasing number of timesensitive, relatively low dollar volume, vehicle rentals which in manyinstances require authorizations to be made in advance, reservations ofvehicles from available geographic and vehicle type selections,monitoring of the rental as it progresses including possibly extendingthe rental under certain circumstances, communications between thevarious parties involved in the transaction to ensure ultimate customersatisfaction, and financial accounting for the transaction includinggenerating invoices and processing them for payment. While a significantportion of the vehicle rental business involves rental for leisure,business travel, etc., another significant business relationship hasdeveloped with insurance companies and the like in what has been termedas the replacement car rental service business. In this business, avehicle insurance company may have many thousands of policyholders whoare eligible to be involved in accidents, and other dislocations of use,requiring that a vehicle be rented for that customer's use while his ownvehicle be made ready again for use. Thus, for this business segment, amulti-tiered business organization such as a vehicle insurance companyrepresents a significant customer for repetitive vehicle rentalservices. To conduct this business in an orderly, time efficient andcost efficient manner, it is necessary that this insurance company hasas its business partner a vehicle rental company which is itselfmulti-tiered, such as the assignee of the present invention. This isbecause the needs, both geographically and in volume, are significantwhich require the dedication of a significant amount of resources. Tosatisfy these needs and to respond to other business growth, in itsembrace of technology the assignee hereof has succeeded in developing anin-house computer system and related software which has integrated itsbusiness internally. This business integration has been massive andcompany-wide as is needed to integrate a company having a central officewith literally thousands of individual branches located nationally, andeven now internationally, with hundreds of thousands of vehiclesavailable for rental. Furthermore, other business partners includingother service providers such as vehicle repair shops have also beengiven access to this system to allow for input of information relatingto progress of vehicle repair, extension of rental time, etc. as therental progresses. This integrated business computer network andsoftware generally includes a mainframe server at the heart of a widearea network (WAN) which facilitates the transfer of vehicle rentalinformation and orders company-wide. This integrated business model ismost efficient and needed in order to satisfy the vehicle rental serviceneeds of a vehicle insurance company which itself may be national oreven international in scope.

As a first step in extending the integration of technology into thisbusiness model, the present assignee has previously developed andimplemented a computer system which has provided improved communicationcapabilities between the two business partners. This system generallycomprised a second mainframe computer linked to the first mainframe ofthe integrated business network, with dedicated access lines beingprovided from this second mainframe to various levels of the multilevelbusiness organization comprising the insurance company. In effect, withthis additional mainframe and dedicated pipeline access, variousindividuals at the insurance company were permitted to directly interactwith the integrated business computer network of the vehicle rentalcompany as well as other selected service providers such as body shopswhere wrecked vehicles were being repaired. The implementation of thissystem provided a great step forward over the people intensive businessactivity previously required in order to handle the large number oftransactions encountered in this business relationship. Historically,the replacement car market engendered large numbers of telephone callsbeing placed between the insurance company, the rental company, and thebody shop where vehicle repair was being performed in order to authorizethe rental, select and secure the desired replacement vehicle to beprovided, monitor the progress of the repair work so that scheduling ofthe rental vehicle could be controlled, extending the vehicle rental inthe event of delays in repair, authorizing various activities involvedin the rental process including upgrades of vehicles or other chargesfor services, and subsequent billing of the rental service andprocessing the billing to the insurance company for payment.

While the implementation of this system was successful and represented atremendous step forward in automating the business relationship betweenthe insurance company and the vehicle rental company, it did havecertain limitations. For example, a specific communication link had tobe established between the rental vehicle company and the particularusers at the insurance company designated to have access to this system.Thus, special attention and some modicum of expense was required toestablish these “pipelines” and maintain them. Still another aspect tothe system implemented was that it was not “browser” based nor did itprovide graphical user interface (GUI) menus. Thus, each user had to bespecifically trained in the particular “language” used by the system andlearn to work with specific menus nested in a specific manner as well ascodes for entering commands which were not similar to other computersoftware programs. This software design thus necessarily requiredadditional training in order to insure that users could gain the fullmeasure of advantage provided by the system and in order to minimize theopportunity for erroneous information or incorrect reservations frombeing entered or otherwise confusing the business transactions.Furthermore, user efficiency was not immediate and required skill beyondthat ordinarily found in casual computer users, as we are all becomingin this computer age. Still another disadvantage to the system was thataccess was required to a designated entry point in the system in orderfor a person authorized to be on the system to work with it. As thenature of the insurance and replacement car business requires extrememobility at multiple levels of both business partners, this represents alimitation to the usefulness and time efficiency with which variousbusiness functions could be performed. Therefore, while implementationof the second mainframe allowing for pipeline connections at variouslevels of the multi-tiered insurance company was a significant stepforward in automating the business relationship between the two businesspartners, significant limitations to this solution were readily apparentto the users thereof.

SUMMARY OF THE INVENTION

In the first parent application cross-referenced above, the inventorsherein have previously succeeded in designing and developing a means forsubstantially enhancing the business to business communication linkbetween these two businesses which provide significant advantages overits prior embodiment. More particularly, the inventors have succeeded inreplacing the dedicated pipeline access of the existing system with aweb portal allowing Internet access to the mainframe with a browserbased graphical user interface (GUI) presentation. This also made thesystem more readily accessible to smaller business partners as theexpense of the “pipeline” was eliminated. The first parent's inventionoffers several important technical advantages over the previous system.First of all, by taking advantage of the ubiquitous nature of theInternet, the ultimate in portability and connectivity for this systemis now provided in a business environment where mobility andconnectivity are at a premium. In other words, a claims adjuster, bodyshop, or any other business employee authorized to have access to thesystem may gain access at any site offering Internet access. In presentday technology that includes many mobile devices and appliances whichare Internet enabled. As technology advances, it is conceivable thatthis access will extend to permit “24/7” access by any authorized personat any geographic location. This is a marked improvement providingimmediate benefit and advantage over the dedicated pipeline access ofthe prior art system.

One limitation however, is that with this embodiment, this internetaccess must support a stateful connection. In this context, a statefulconnection refers to a “persistent” conversation, meaning that theclient side and server side software components establish a connectionto one another once and multiple data transfers may occur withoutsevering that connection. Common examples of a stateful connectioninclude on-line chat, on-line gaming, and for virtually all on-lineconferencing. This is distinguishable from the normal operation of webpages which typically establish a connection, transfer the object on thepage, and then sever that connection. These types of connections aregenerally referred to as “stateless” connections.

A second major advantage of the first parent's invention is itsgraphical user interface. The inventors have taken full advantage ofthis browser based GUI to streamline and organize the presentation ofinformation to a user to actually guide him as he interacts in doing hisbusiness. One such example is customized design of the menus such thatthe user is guided and directed to answer only those questions requiredto be answered in order to conduct the particular transaction beingaddressed, and further to present choices to the user for his selectionto minimize the need for the user to rely on his own memory or to befamiliar with complicated and specialized codes to enter data or requesttransaction activity. With the recent and continuing explosion of theInternet, more people are becoming familiar with browser programs andtheir operation through their own daily activities in their personallives. This familiarity paves the way for easier training and quickerorientation of a new user to the present invention. For large businessorganizations communicating at multiple levels, this significantadvantage cannot be minimized as there are large numbers of people whomust be continuously trained due to the growth of the organizations, aswell as the replacement of employees due to the inevitable attrition.Thus, the first parent's invention provides an immediate increase inworker productivity, and makes that improved efficiency available tomany more workers who are not particularly skilled otherwise in computerusage.

Still another advantage provided by the first parent's invention isthrough the implementation of additional functionalities which areengendered by the browser/GUI interface. As the system is continuouslyused, and feedback is continuously monitored and analyzed, additionalfeatures that add value through providing management information as wellas by speeding transaction activity over the system may be implemented.For example, several of these features include the ability of a user tocreate an on demand report for transaction activity including summariesof transactions handled by a particular user or group of users whichmight either be open or closed. Another example of additionalfunctionality which improves the efficiency of a user is the ability tocreate a repair facility call back list which allows a user to sortexisting open vehicle rental reservations by repair facility (body shop)and date such that a user is presented with the list of openreservations at a particular repair facility which can be readilyhandled in a single telephone call while at the same time having thesystem on line to implement any needed changes such as extensions ofreservations, etc. Additional functionality has also been provided tospeed the processing of invoicing which of course also speeds theirpayment and cash receipts. For example, it was found that even despitethe built-in error checking and correction facilities provided to theusers of the system, a repetitive pattern of mistakes involvingincorrect claim numbers was discovered. To speed the processing ofthese, an additional functionality was provided as an “electronic audit”known as invoice return which returns an invoice to a particularadjuster upon detection of an incorrect claim number for his humanintervention and correction of the claim number. In this manner, probleminvoices exhibiting one of the most common problems encountered may bereadily handled within the system and in an efficient manner, instead ofmanually as before.

The first parent's invention also has as a significant advantage theability to be further customized to meet the individual businesspartners' needs and desires as well as to provide additionalfunctionality by offering additional features which become desirableupon accumulation of user data based on user experience. Furthermore,once implemented, they are immediately available system wide. While thisallows for consistent usage, it is limited in the sense that all of thesystem users are forced to use the same menus, data definitions, etc.This is not seen as a limitation for the one-to-one business applicationintended to be primarily addressed by the first parent's invention.

Still another advantage of the first parent's invention is that thegraphical user interface incorporates point and click interaction, usingbuttons and tabs to present or conceal data for the user's attention orinattention as the case may be, and provide a much more robustinteraction capability through the creation of menu designs that allowfor access to the most commonly needed features from any point in themenu architecture. This is to be contrasted with the prior system whichconsisted of a main frame character based interface while the firstparent's invention with its GUI interface allows a user to point andclick to navigate and to make selections by pull down selection, therebyreducing errors. As users become more experienced with the system, andtheir confidence level grows, they are much more likely to become boredand aggravated with the rigid structure of the prior system requiringthem to follow along a certain menu architecture in order to completecertain tasks. On the other hand, the first parent's invention generallyincreases the interest of the user in using the system. These advantagesof the first parent's invention over the prior interface promoteemployee productivity by allowing a user more control over his workwhich is critical in achieving savings in human resources to operate thesystem which is one of its main goals.

The second parent's invention extends the first parent's invention andexpands its capabilities and functionalities. With the second parent'sinvention, a user may not only have access to its business partner, butalso one or more competitors of its business partner through the sameInternet portal. In this way, at least two needs are satisfied. First,the user can have access to a variety of providers to choose from wherebusiness needs or desires require. This allows the user to use a singleportal and not have to sign on to a number of different portals, evenshould they be available. Furthermore, the user isn't troubled to learnhow to access and use different portals even should they be available.Presently, not all providers are operating an Internet portal foroffering their services, so by allowing business competitors to beaccessible through the same portal, independent development of otherportals is forestalled. This is a benefit to the operator of the mainportal as it creates and maintains a competitive advantage by handlingall of the order flow which creates a data base of useful informationfor marketing purposes. Although initially the portal services might beoffered for no additional cost to a competitor, eventually a fee mightbe charged which would at least partially offset the cost for owning andoperating the portal.

The design of the portal is elegant and offers great flexibility forcustomizing not only the menus for presentation to the user, but also inthe design of the data base entries needed or desired by the user and/orthe competitive provider. For example, some users might not know or careabout the features of a vehicle rented and so those data entries may notbe provided space on the menu for the user to fill in. The data base ashandled by the networked computer system then need not keep track ofthat data for that customer. This feature is readily accommodated by thedata base programming and is conveniently implemented.

In still another aspect of the second parent's invention, the web portalhas the capability to accommodate the varying data requirements also ofthe various competitive providers, but also the level of theirsophistication as evidenced in their respective computer systems andinterface facilities. For example, the web portal may be configured tocommunicate the users order to the competitive provider via email,phone, or even through a connection directly to an integrated computersystem having the same or substantially the same inter-operability asthe integrated computer system of the assignee hereof. This capabilityextends to accommodating and matching the competing data requirements ofthe user and the competitive providers, and having the flexibility todesign and implement menus that readily meet these competing needs.Furthermore, the second parent's invention allows for changes to beimplemented by simple re-programming of the web portal which minimizesthe effort and enhances the “user friendly” aspect to the presentinvention.

Not only are these “global” improvements made available with the secondparent's invention, there are other more particularized improvementsthat add functionality within the operating framework of the secondparent's invention. For example, one such improvement is the ability to“virtually” assign work groups within the user so that, for example,multiple adjusters might be made into a team with a shared work load sothat all of the team members have access to the same pool of work, suchas the placing of reservations for the same group of drivers. With this“virtual team” assignment capability, work groups may be readilyre-assigned to match changing work loads without worrying aboutre-configuring hardware or internal network connections. This can be avery valuable feature to accommodate staffing issues over geographicaldistances that can be nationwide, with access through the web portal toreservation facilities which are themselves nationwide.

Still another feature is the ability to customize an individual usersauthorization limits. As can be appreciated, one of the mixed blessingsof providing enhanced functionality to the individual users of anyintegrated computer system is that it places great power in the hands ofthe user which at the same time creates the potential for abuse. Therehave been well publicized instances of “rogue” employees makingfinancial decisions or placing instructions which have far reachingfinancial consequences well beyond the intended authority of anemployee, with disastrous results. With the second parent's invention,one feature is the ability to limit the financial commitments that auser may make during any pre-selected time period. For example, theusers profile may limit his ability to make only a certain dollar limitof vehicle reservations over any certain number of work days. In thisway, added safe guards may be conveniently provided, monitored byreporting capabilities, and changed as circumstances warrant, all withsimple programming changes at the web portal.

There are still other features that are provided by the second parent'sinvention that find their genesis in the different approach taken overthe first parent's invention and owing to the inherent increasedflexibility of using a web based programming for the web portal tointerface between the user and the providers on the web server andeliminating the need for any custom software on the users terminal. Thedetails of these are to be found and described in the detaileddescription of the preferred embodiment below. Examples include theability to send confirmatory communications to the user that thereservation has been received and entered into the providers system forfulfillment, custom report design including the capability to save andre-generate the custom report upon user command, increased flexibilityto process and pay invoices, etc.

Still other advantages and features have been developed and are newlydisclosed and claimed more particularly herein. These advantages andfeatures relate to usage of the present invention both domestically andabroad where there are idiosyncrasies in the business model that need tobe accommodated. Still other features provide entirely newfunctionality. One such new feature involves adapting the presentinvention as a tool to market replacement vehicles for sale or lease toa customer who has had an accident significant enough that repair of hisvehicle is not economically feasible. This is commonly referred to“totaling” a vehicle. The insurance industry totals about 3 million carsper year, of which approximately 17% are newer models (defined as withinthree years of current model year). Once totaled, the owner needs to buyanother car. Since car rental companies desire to sell more cars, anyopportunity to tap into the total loss market will be bountiful.

The present invention provides a window into the establishment of atotal loss for a renter's/insured's/claimant's automobile. Any car thatis deemed to be a total loss would be indicated as such in the presentinvention for reporting purposes. At this point the stored informationcould be used to help provide economic benefit to all parties, insurancecompany, rental car company, and automobile owner.

Once a renter's/insured's/claimant's (owners) car is determined to be atotal loss the adjuster will try to ascertain the actual cash value(ACV) to be settled with the owner. The adjuster can use a third partytool, such as CCC's Pathways® product, to determine what ACV is. Todayan adjuster must input this information manually into a separateapplication. The present invention contains much of the necessaryinformation needed to determine ACV: name, car make, model series, year.The present invention need merely send the necessary informationelectronically to a total loss product and request an electronicresponse. Once the necessary information is generated, the presentinvention would in turn take the ACV and cross reference the car rentaldatabase of inventory. Necessary information might include but not belimited to: ACV, year, make, model series, comparable cars, etc.

The car rental inventory can be filtered by geography and “holdingrequirements”. As a reseller of vehicles, the car rental inventory isgenerally contractually required to be within the fleet as a rental fora predetermined amount of time prior to being available for sale tothird parties. Once a car is past the holding requirement it isgenerally within the discretion of the car rental company to sell. Thus,instead of X % of cars available to the car rental company for retailsale, a virtual inventory of cars is available for retail sale to theowner of the car.

Once the filters for geography and holding requirements are active, thepresent invention delivers a list of available vehicles for sale. Atthis point the adjuster and owner review the available cars, decide thecars considered to be attractive, and the owner then decides which onehe wishes to purchase.

The user then selects one or more potential vehicles and sends therequest to the appropriate car rental location. The car rental locationcan then contact the owner of the vehicle to buy one of the selectedvehicles. In addition, the list of vehicles and ACV information can besent to the owner for further review and discussion.

Once the car rental company contacts the owner and comes to a sufficientconclusion, either to buy or not to buy, the adjuster is notified of theconclusion and the transaction is consummated either through the presentinvention or off-line.

Still other features are disclosed and claimed herein which extend thefunctionality of the present invention. These include the following. Onesuch feature is providing for automatic extensions of existing rentalauthorization, so that some limited extension authority is granted topermit some flexibility to a particular user without burdening him withthe need to obtain approval for the extension. Another feature could bereferred to offline usage, and provides the functional advantage ofpermitting processing of reservation data in a computer not connectedinto the network, and then uploading/downloading between the offlinecomputer as it is connected into the network, such as by dialing intothe network over the internet, or through a portal. The type of datawhich could be processed includes virtually any related to theprocessing of vehicle rental transactions and other related data such ascar repair scheduling, etc. This functionality provides an extension ofthe usability to the invention to mobile users who travel beyond thereach of the internet, which even further enhances its applicability tothose places not covered by wireless coverage. Alternatively, it allowsthe invention to bypass special connectivity issues which are thought tobe disadvantageous for any reason including cost, unavailability,inconvenience, etc. Still another feature includes further integrationof the internal data bases kept by permitting a user to automaticallyupdate not just one but several data bases with a single command oncethat new data is entered into a single menu. For example, in what can bereferred to as “power templates”, a user may enter a multiple number ofrental reservations on a single menu and then click a single “approved”icon which would then enter all of them into the system. This representsan improvement over a previous implementation requiring a user toseparately “approve” each reservation, and then suffer the systemprocessing time for each reservation. This “batch” processing can resultin significant improvement in throughput, and reduction of userinterface time for processing multiple transactions. Still anotherfeature provides the added functionality of processing customersatisfaction feedback through the system. This feature provides thecapability for a user to enter customer feedback information, bothpositive and negative but perhaps more importantly negative, so thatimmediate awareness of any problem can be obtained and corrective actiontaken to mitigate or eliminate the difficulty. This feature also allowsa user to indicate a suggested supervisory level of interaction, or thesystem may allow for automatic escalation of involvement for succeedinglevels of supervisory attention as the dissatisfaction continues or evenescalates. This feature can be significant to a service provider as theultimate success of a service provider is directly dependent on theperception of satisfaction by the end customer. And, it is well knownthat the sooner a problem is identified and solved, the more likely acustomer will have a satisfactory experience. Furthermore, from a stricteconomic viewpoint, the sooner some problem is addressed and solved,generally the less expensive the solution. A small accommodation canchange a frown to a smile, if promptly offered.

Still other features are now disclosed that have applicability perhapsin the domestic business model, but certainly offer needed functionalityin other business models found in other countries. One of these includesmultiple party involvement/management of a rental transaction. While theflexibility of allowing multiple adjusters within a group to “work on” arental transaction has been previously described, this particularfeature is different in that not only may these multiple adjusters notbe within the same group, they might not be employed by the sameemployer, might not be adjusters themselves, and might have differentauthority for action on the transaction as is commonly found indifferent countries. For example, in some countries one adjusterauthorizes and manages the rental reservation for the car while anotheradjuster authorizes and manages the insurance coverage for the rental.Still another feature allows third party or “independent party”management of the rental. In some countries a third party other than aninsurance company is involved, such as a “credit hire” or “assistcompanies” or “repair facility” or “lawyer” or “fleet managementcompany”. Each of these third parties, or any other third party, may bepermitted access to the system and a user profile created for them thatdefines their authority to process rental transactions through anadministrative profile set up in advance through agreement with theauthorizing agent, such as an insurance company. As an enhancement,various individualized features may also provide data indigenous to aparticular country, such as electronic access to the Schwackliste bookfor an adjuster to conveniently view a “class” for a car to determinewhat replacement vehicle is legally authorized for rental. Still anotherexample of a feature needed to accommodate international capability is aneed for a tiered rate system, and an hourly rental charge instead of adaily charge which predominates the domestic market. Processing ofelectronic signatures to satisfy local custom or legal requirement isyet another example of a feature for which the present invention isuniquely suited to provide.

While the principal advantages and features of the invention have beendiscussed above, a greater understanding of the invention including afuller description of its other advantages and features may be attainedby referring to the drawings and the detailed description of thepreferred embodiment which follow.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of the computer systems comprising thefirst parent's invention;

FIG. 2 is a flow chart of the software programs which communicate overthe computer systems of FIG. 1 to implement the first parent'sinvention; and

FIG. 3 is a schematic diagram of the computer systems comprising thesecond parent's invention;

FIGS. 4-91 are flow diagrams for software resident on the mainframeAS/400 computer 32 as described in Exhibits B and C;

FIGS. 92-159 are a series of flow diagrams and screenshots for theARMS/WEB application software resident on servers 70 as described inExhibit E;

FIG. 160 illustrates a plurality of automated extensions process flowoptions;

FIG. 161 illustrates an exemplary “Extend Rental” screenshot;

FIGS. 162-164 describe a synching function for an embodiment;

FIGS. 165-167 describe a power template function for an embodiment;

FIGS. 168-171 describe a technique for collecting user satisfactionfeedback for an embodiment;

FIGS. 172-184 describe features for embodiments whereby multipleadjusters and/or multiple parties are able to share management ofreservations; and

FIGS. 185-187 describe a technique for identifying replacement vehiclesfor total losses.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The overall system architecture for the first parent's invention 20 isbest shown in FIG. 1. As shown therein, an insurance company computersystem 22, which itself may be virtually any computer configuration oreven a stand alone PC accesses the Internet 24 through any convenientaccess point 26 such as even including an ISP (Internet serviceprovider), as known in the art. Also connected to the Internet 24 is aweb portal 28 which is preferably provided by a server appropriatelyprogrammed as explained herein below. This web portal 28 may beappropriately configured as desired to suit any particular businessrelationship or arrangement, although preferably the inventors hereinand assignee of this invention have determined that a 24/7 or full timeconnection to the Internet 24 is preferable, except for scheduleddowntimes for maintenance, etc. The service provider 30 which forpurposes of explaining the first parent's preferred embodiment ispreferably a vehicle rental organization, has itself an Internet portalmainframe 32 connected by a bi-directional communication link 34 to asecond computer network 36 which may itself preferably have a mainframeserver 38. This second computer system 36 is preferably a network havinga database 40 for communication with what may be thousands of branchoffices each of which has its own computer interface 44 whichcommunicates to this second mainframe server 38 to conduct theintegrated business functions of a service provider organization.Instead of communicating with the branch offices directly, a reservationmay be communicated to a centralized location for further processing,such as a call center, and then relayed on to an appropriate branchoffice. This might be desirable under certain circumstances, such as ifa branch office is closed, or when a purchaser requires some specializedservice such as close monitoring of the rental. This may be doneelectronically and automatically, or with human intervention.

It should be noted that the particular computer configuration chosen asthe preferred embodiment of the first parent's invention may itself besubject to wide variation. Furthermore, the term “mainframe” as usedherein refers solely to a computer which can provide large scaleprocessing of large numbers of transactions in a timely enough manner tosuit the particular business application. Preferably, as is presentlyused by the assignee hereof, an IBM AS/400 mainframe computer is used aseach of computers 32, 38. However, as is well known in the art, computertechnology is subject to rapid change and it is difficult if notimpossible to predict how these computer systems may evolve astechnology advances in this art. For example, it is not beyond the realmof possibility that in the not so distant future a network of computerswould provide the processing power to conduct these business operationsas presently handled by “mainframe” computers. Thus, the term“mainframe” is not used in a limiting sense but merely to indicate thatit is descriptive of a computer suited to handle the processing needsfor a large scale business application.

It should also be noted that the communication link 46 extending betweenthe server 42 and each of the branch offices 44 may have alternativeconfigurations. For example, in some applications access over theInternet may itself be adequate, recognizing the vagaries of Internetservice availability, reliability, and processing speed. Alternatively,this communication link 46 could well be a dedicated pipeline providingbroadband service connection full time with back up connections toensure continuous communication between a particular branch office orgroups of branch offices and the service providers business operationscomputer system 36. Some branch offices might even be served throughsatellite links. Indeed, it is even possible that a mixture of thesewide variations of service level be present within a singleorganization's structure depending upon communication link cost andavailability balanced against service needs. It should merely be notedfor present purposes that this communication link 46 serves as theelectronic umbilical cord through which branch offices 44 communicatewith the business computer system 36 of the invention.

Attached hereto as exhibits are functional descriptions of the softwareprograms resident on the computers comprising the two computer systems32, 38 which implement the first parent's invention. More particularly,attached hereto as Exhibit A is a functional description of the softwareto implement the integrated business functions resident on the AS/400 ormainframe computer 38. Attached hereto as Exhibits B and C are relatedflow diagrams (see FIGS. 4-91 of Exhibit B) and explanatory text,respectively, for the software resident on the mainframe AS/400 computer32. Attached hereto as Exhibit D is a functional description of thesoftware resident on computer 32 but which also appears on the server 28which creates the web portal for access to the mainframe 32 and itsresident program. Server 28 may use a bi-directional GUI to characterbased interface translator program, well known to those skilled in theart, to present the displays and information obtained and transmittedbetween the user and the computer 32. However, the software of Exhibit Dcould also be run on server 28, as would be appreciated by those ofskill in the art. It is believed that these functional descriptions andaccompanying text as exemplified in these exhibits are adequate toenable an ordinary programmer to implement corresponding softwareprograms for executing the preferred embodiment of the first parent'sinvention using ordinary programming skills and without inventiveeffort.

As a further example of the flow of data and the functional advantagesprovided by the first parent's invention, reference is made to FIG. 2.As shown therein, a right hand column is identified as “ECARS” whichrepresents the integrated business software implemented as part of themainframe operation 38 in computer network 36. The center column headed“ARMS” is resident on mainframe computer 32 and coordinates thecommunication of data. The left column headed “ARMS/WEB” represents thesoftware resident on computer but which is presented on server 28 andaccessible by users through the Internet. Along the left side of FIG. 2are designated three separate sections of operational activity. Theseare “reservation” followed by “open” and concluded by “close”.Generally, the functional descriptions are arranged in chronologicalorder proceeding from the top of FIG. 2 to the bottom. However, somefunctional features are permitted throughout the entirety of one of thethree periods designated at the left side of FIG. 2. One such example isthe “message” function which allows messages to be sent between users atone business organization 22 and branch offices 44 and others connectedto the other business organization 30. Proceeding with a description ofthe transaction, the first set of communications allow for thereservation of the services. These can include requests forauthorization or a rescind authorization request to be sent from theservice provider to the service purchaser. Correspondingly,authorizations and authorization cancels can be sent from the servicespurchaser to the services provider. Confirmations are communicated uponconfirmation of an authorized reservation request. Authorization changesmay be made and communicated from the services purchaser to the serviceprovider. Corresponding rental transaction changes may be communicatedfrom the services provider to the services purchaser. As indicated,through the entirety of this process messages may be sent between usersand others connected or having access to the integrated businesssoftware, as desired. The consummation of this portion of thetransaction is a reservation that has been placed, authorized,confirmed, and provision is made for changes as necessary. During thenext phase of the transaction, a reservation is opened and servicesintended to be provided are started. Generally, and preferably for therental of vehicles, a start and end date are established in thereservation process. However, along the way, transactional changes maybe made, such as for changing the type of vehicle provided, extensionsmay be requested and entered from either business partner, messages maybe transmitted between the business partners, and the transaction may beterminated such as by voiding the contract by one business partner orterminating the authority by the other business partner. The term“reservation” has been used herein to refer not only to the act ofplacing the order but also to filling the order for services includingproviding the rental vehicle to the ultimate user and even invoicing forthose services.

The last phase of the process involves closing the transaction. Duringthis phase of the transaction, the contract is indicated as being closedand invoiced, the services purchaser can approve invoices, rejectinvoices, and also remit invoices. Such invoice remittance may alsoinclude the actual transfer of funds through an electronic fundstransfer medium, or otherwise as previously arranged between thebusiness partners.

It should be understood that this is a streamlined description of thehandling of a transaction, and by no means is exhaustive. For example,much more functionality is available to the user including accessing thedata base to generate production reports regarding status of open orclosed reservations, preparing action item lists to allow a user toorganize and prioritize his work, obtaining information available in thesystem from having been entered by others which would otherwise requirephone conversations which are inefficient and occupy still anotherperson's time. A more detailed explanation of the functionality providedis found in the exhibits.

In summary, the first parent's invention creates almost an illusion thatthe services purchaser, and the great number of users at various levelsof the multi-tier purchaser users, are actually part of the servicesprovider organization in that immediate online access is provided tosignificant data which enable the user to make reservations forservices, monitor those services as they are being provided, communicatewith those providing the services, obtain information relating to thestatus of services as they are being provided, and close transactions,all by interacting with the services provider business organization overthat user's PC and without human interaction required by the businessproviders personnel. By way of contra-distinction, for many yearsbusiness has been conducted on a human level by customers picking up thetelephone and calling services providers and talking to their humancounterparts in order to convey information, place orders, monitororders, including obtaining information as to status, canceling orders,questioning invoices and paying invoices, along with a myriad of otherrelated interactions. Not only did the conduct of business in thismanner entail significant amounts of human resources at both ends of thetransaction, but it also led to inefficiencies, mistakes and delays allof which increase the cost of doing business and contribute to anincreased risk of services being rendered in an unsatisfactory manner inmany instances to the end user. The first parent's invention has takenthe preexisting solution of providing electronic communication betweenthe business partners to another level by “web enabling” this system forimproved connectivity, improved usability, reduced training, enhancedmobility, and other advantages as described herein.

A schematic diagram of the second parent's invention is shown in FIG. 3and includes three levels of architecture. As shown in the first levelof the architecture 50, a user 52 such as an insurance company or otheruser has access through the Internet 54 to the computer systemcomprising and incorporating the invention. An Internet providerprovides a link 56 through which Internet connections may be made tocommunicate with the further described system. For convenience, thisInternet connection may be considered as an Internet site or portal inthat a user enters a URL and arrives at this connection. A firewall 58as is known in the art is used for security purposes and to preventhackers and the like from unauthorized access to the system. A first setof servers 60 are interconnected in a network 62 and may preferablyinclude an ancillary server 64 for running load balancing software orthe like to balance the load and provide redundancy amongst what may bea plurality of web servers 60. These web servers 60 may preferably beSun Microsystem servers running Apache web server software, or othersuch suitable software as would be well known to those of ordinary skillin the art. This first web server network of servers 60, 62 process therandom and disorderly communications flowing to and from this system andthe Internet before passing them through a firewall 66 as a furtherprecautionary measure. This first layer of architecture, identified asthe Internet space/DMZ layer provides a secure interface and createsorder out of the chaos of communications flowing between the system andothers, as will be described.

With this architecture, stateless connections are accommodated, for thefirst time. By supporting stateless connections, this embodimenteliminates the implementation difficulties encountered with the firstparent's embodiment on the client. These implementation difficultiesinclude installing extra software on the client side computers, andeliminates the need for special configuration of the internet accessmethod, such as proxy servers or routers. For example, many proxy serverare configured to disallow stateful connections for security reasons,i.e. to prevent unauthorized programs from establishing suchconnections. Another example is that routers are customarily configuredwith most ports closed and thereby unable to support statefulconnections.

The next layer of architecture 68 is noted in the figure as the“Enterprise private network” and is comprised of a plurality of servers70 network connected with a network connection 72. Again, although thechoice of hardware is not considered critical by the inventors hereof,Sun Microsystem's server/work station hardware is preferably used toprovide the platform for running the application software for processingthe various rental vehicle transactions, as will now be explained.Attached hereto as Exhibit E are a series of functional designspecifications for the ARMS/WEB application software resident on servers70 and which provide the detailed description of the operationalfeatures of the software and system. With these functional designspecifications for the individual modules, it would be readily apparentto those of ordinary skill in the art that programmers of ordinary skillwould be able to write software to execute these functionalspecifications without using inventive effort. Furthermore, the detailsof this implementation are not considered to provide any aspect of thebest mode for carrying out the invention which is defined by the claimsbelow.

Generally, the ARMS/WEB application software permits a user to sign onand, when recognized, provides the series of menus presenting choicesfor the user to indicate the parameters for his reservation. A plethoraof information is provided and accessible to the user through thevarious menus provided from which the user selects and enters data toprocess the reservation. An important feature of the ARMS/WEBapplication software is that it provides the user the opportunity toselect to place his vehicle rental reservation not only with theintegrated business computer system represented by the third level ofarchitecture 74, described below, but also to route the reservationinformation back through the first architectural level 50 and into theInternet 54 for transmission to a competitive service provider 76.Although the interconnection is depicted in FIG. 3 as being made throughthe Internet 54, the network of servers 70 configured in accordance withthe ARMS/WEB application software may utilize virtually any electronicmeans for transmitting the reservation information to a competitiveservices provider 76. These include email, automated telephone,facsimile, and other forms of electronic communication. Of course, thecompetitive services provider 76 may itself comprise an integratedbusiness such that the level of interconnectivity provided to the user52 may parallel that disclosed and described in connection with theintegrated services provider system of the invention as well as thefirst parent's invention. This integrated business capability isrepresented as the third level 74 of the architectural topography shownin FIG. 3 which parallels portions of that shown in FIG. 1 in that apair of network mainframe computers, such as AS/400's 78, 80 may processreservations to and from various branch offices 82 which aregeographically diverse.

With the invention, the Internet portal provided by the ARMS/WEB networkconfigured servers 70 provide an Internet portal for communication withnot only the integrated computer enabled business system of the residentservices provider, but also a portal for placing reservations to othercompetitive services providers 76. Thus, the user 52 enjoys thecapability of accessing multiple service providers for competitiveservices through a single Internet connection using a single set ofprotocols, menus, etc. for the conduct of this business activity.Furthermore, the software configured network of servers 70 is readilyconfigured in Web Logic to adapt to changing user requirements, datarequirements, unique competitive service provider requirements, andother upgrades or modifications in a convenient manner by simplymodifying the software resident therein. No special browser software ofother interface software is required by the user and any specialinterconnecting software or server/hardware requirements may besatisfied as between the service providers such that the user ispresented with a seamless interconnection. As the invention isconfigured and works well with the integrated business and computersystems as disclosed herein, it is anticipated that such interconnectionand usability may be readily translated to any other such integratedcomputer system as might be found in other competitive serviceproviders, as would be apparent to those of ordinary skill in the art.Thus, with the invention, a user is provided with among other thingsInternet access through a single portal to a plurality of serviceproviders and, to the extent possible, to their integrated computerbusiness systems.

The invention is sufficiently flexible to accommodate changes which areintended to adapt it for use with other business models, and especiallythose encountered in other countries. Furthermore, some of these changesadd features that are equally applicable domestically. One such exampleis an “automated extensions” feature. Typically, there are manyoccasions when a damaged or inconvenienced vehicle is not made availablefor use when originally scheduled. In the prior art, many times anextension would then need to be requested through the system, withauthorization requested and provided. In order to streamline thisprocess, and to minimize delay and involvement of supervisory authority,the system may provide for some form of automatic extension authority.Preferably, this could be provided in any one of three modalities (seeFIG. 160), or some combination thereof. A first modality as exemplifiedby FIG. 160 (option 1) would be for the service provider to haveautomatic extension authority, upon communication to the customer,within certain pre-determined limits. For example, an initialauthorization may be for 12 days of a vehicle rental. A request for anextension of 5 days may be made by the service provider and of that 5days 3 days may be authorized automatically as being within 25% of theoriginal rental term and a request for the additional 2 days requiringapproval may be automatically generated. Still another variation asexemplified by FIG. 160 (option 2) would be for the insurance company toset a limit within the system of the total number of authorized days,which could be based on some other parameter such as labor hours or bodyshop hours or down time for the repairs to take place. Then, uponrequest for an extension, one may be automatically granted based on thetotal authority allowed or initially set into the system by theinsurance company, and up to that limit. Still another variation asexemplified by FIG. 160 (option 3) would be for a third party serviceprovider to be involved in the process, such as a body shop, to makedirect input into the system of a need for an extension. Theseauthorized third party providers would preferably be pre-selected andtheir authority limited as described above. This feature may beimplemented conveniently in a separate menu, for example as shown in theattached “screen shots” headed “Extend Rental” (see FIG. 161).

Another feature is an offline usage feature which allows a user, such asan adjuster, to work with a laptop having loaded thereon a softwareprogram that emulates the connected network software for localprocessing of data, such as claims data (see FIG. 164). In use, anadjuster would preferably first connect to the system and download or“synch” his laptop data base with the claims data resident in thesystem. The adjuster would then disconnect and use his local program towork offline. Such work could include the generation of newreservations, authorization of direct billings, extension of rentals,approval of invoices, and setting of termination dates for on-goingrentals, among other tasks. The user would then re-connect to thesystem, such as over an internet connection, sign in, and “synch” hislaptop to the system which then transmits or executes hiscommands/communications to the central processor. The central processorchecks the users “synch” data against its data file, advises the user ofany “synch” data that is older than the current data, and requests theuser to specify which data should be processed. After the processor isinstructed by the user, it will then act on the “synch” data. Forclarity, a first “screen shot” (see FIG. 163) is provided thatillustrates a sign in log for a user who wants to initiate a “synch”,and a second “screen shot” (see FIG. 162) is provided to illustrate alisting of activity that could have been created offline and which isavailable to be input to the system upon “synching”. A preferencesfeature is provided to allow a user to establish defaults for automaticsynching of the data. Other preferences would include options on howsynching issues when offline and main system transactions are updated.Also, a history feature will allow the user to display all of thesynching activity from his connection or portal (e.g., a display of allof the snych events over a specified period of time) including errormessages and conflicts noted (e.g., resolution to synch conflicts (i.e.,the main system was updated after the local record was updated whichrecord takes precedence)).

Yet another feature allows for a user to enter, or execute, a full menuof transactions without individually opening them from a summary menu(see FIG. 165). This has been referred to as a “power template” feature.The purpose of the power templates is to allow the adjuster to quicklyupdate all action items without having to go into the details. Theadjuster is presented with the required information to extend,authorize, approve invoice, or set last day on the rental. If theadjuster wishes to view the details, a hyperlink is provided to allow auser to jump into another menu of details for an individual item shouldit need to be changed and not entered as suggested, requested or listedon a users action list. FIG. 167 shows an administrative feature wherebya user's defined preferences can include options to list managementtasks for each of extensions, direct bill requests, and invoice billingas a list or individually. FIG. 166 shows an action items list where 4extension management tasks are displayed as a group for selection toaccess the power template of FIG. 165.

Still another feature allows for the collection of user satisfactionfeedback, and alerts to be entered for the attention to complaints, bythe user right at his terminal (see FIGS. 168-171). This capabilityallows for a text message to be entered as well as the name and contactinformation of the party making the feedback. As known in the serviceindustry, and as discussed above, customer satisfaction is important andthe faster a complaint can be registered and communicated to the properperson for correction, and then corrected, the more likely that acustomer will view his experience favorably. By providing a pop up menuitem capability, a user may from any one of a number of menus (see FIGS.168 and 169) immediately enter the description of the problem and sendit to the proper person electronically with a minimal amount of effortand a high degree of reliability. A convenient record may then be madeof these “feedback” issues and entered into the system database. Withthis information stored electronically, it may be conveniently searchedand analyzed for any recurring patterns, thereby identifying anyparticular person, branch, facility, or type of problem that should beaddressed for action beyond the solution of the immediate problem. A“screen shot” is provided to illustrate how the “pop up” menu may appear(see FIG. 169), although it could be varied to allow for entry of otheror additional information such as “trouble codes” allowing for the typeof problem to be user classified, etc. A flow diagram (see FIG. 171) isalso provided to illustrate the flow for complaints, a methodology forprocessing them including escalating their importance and level ofattention as the matter remains unresolved over time.

Still another feature that adds to the flexibility of the invention is amultiple adjuster feature (see FIG. 174), that can be extended toinclude an independent party control feature. In some countries, and insome business models either domestically or abroad, it may be preferableto have more than one adjuster be empowered to interact with orauthorize certain facets of a vehicle rental transaction. In thosesituations, the invention can provide the flexibility and control neededto separately empower and control the interaction of multiple adjusters.For each user of the invention, an “Administration” schedule is set upby an authorizing agent, such as someone at the supervisory level ofeither the insurance company or the service provider, which grantsauthority for performing certain work activities as well as possiblylimiting the amount of monetary authority allowed that adjuster. A“screen shot” (see FIG. 183) is attached which exemplifies suchauthorization, with work activities including creating/authorizingreservations, maintain/extend rentals, pay invoices, user maintenance,receive unassigned action items, and reporting. This capability could beused to separately authorize different adjusters acting on behalf of theinsurance company and the individual. In other words, the individual mayneed the car for 5 days but the individual's insurance coverage may onlyapply for 3 days while the insurance may pay for five days rental. Thiscapability may also be further extended to independent third parties.

An independent party constitutes a third-party management organizationthat an insurance company may give permission to manage some or all ofthe rental transaction. As extended for independent party management,this capability further adapts the invention for use with agencies suchas “credit hire” (see FIGS. 178-179), “lawyer” (see FIG. 183), “fleetmanagement companies”, or “repair facility” (see FIGS. 177 and 181-182),or “assist companies” (see FIGS. 175-176), all of which are found inother than domestic markets. A credit hire is a lawyer in England thatrepresents clients before a claim is filed. The lawyer (credit hire)helps his/her client get access to rentals, deals with the body shop andmedical providers. The credit hire is hired by the renter, or by theperson who was involved in the accident. The “lawyer” is similar to thecredit hire—this person manages the claim for his/her client. InEngland, this role is called “Credit Hire”, in Germany it is called“Lawyer”. Typically, a fleet management company takes care of a fleetfor a company, manages the car hire paperwork and authorizations forreplacement rentals that are needed when a fleet car is in the shop. Anassist company will take on the task of managing the rental process onbehalf of the insurance company in managing the rental portion of theclaim due to an accident. Functions for each “role” vary by theinsurance company authorizing permissions. The chart and descriptionbelow attempt to explain each permission as it pertains to each entityoutlined above.

Receive Create/ Maintain/ Unassigned Own Authorize Extend Pay UserReporting Action files* Reservations Rentals Invoice Maintenance**(Management) Items Credit Hire X X X X X X (Lawyer) Fleet X X X X X X XManagement Company Assist X X X X X X Company *Own files: thisauthorization, if granted, will allow the user to have a file (or claim)assigned to him or her. **User Maintenance: A person that is authorizedwith this capability has the ability to maintain the authorization forother users within his organization. For example, person “B” at ABCcompany has access to “user maintenance.” Person B can assign the accessfor persons C and A at ABC company, but not for Mr. D at DEFcorporation.Included herewith is FIG. 180 which further explains the different typesof independent parties routinely found at present, and examples of“screen shots” (see FIGS. 172, 173, 183, and 184) which provide theadditional functionality of customizing authorizations for each of theseindependent parties for interacting with a rental transaction.

Yet another feature provided by the invention is a facility formarketing cars for sale/lease to customers. As explained above, acustomer will occasionally be forced to replace his vehicle at the sametime that he is renting a vehicle for temporary use. Furthermore, thevalue of the replacement vehicle, or the approved value that aninsurance company will allow under coverage, many times determines theavailable vehicles from which a customer will be allowed to selectwithout personal expense. The invention is uniquely designed to providea listing of available cars, and information about the cars, all fromthe existing rental car data base as is kept in routinely running therental car company's main business of renting cars. It is a simplematter to provide a menu which allows a user to specify search throughthe car inventory with parameters such as zip code, vehicle category,make and model. Using any one or more of these parameters, a searchinquiry will then produce a listing of available vehicles matching theparameters, along with additional information about the vehicleincluding mileage, selling price, and color as well as otheraccessories. A customer could then be advised of the search results andallowed to select a vehicle. The invention may, if agreed to by theinsurance company, and possibly conditioned on the physical inspectionof the car by the customer, then authorize the transfer of the vehicleto the customer as an outright settlement of his claim.

In implementing the replacement of the customers vehicle, a processpreferably comprises the steps of an adjuster identifying the loss as atotal loss which is preferably entered at the same time that areplacement vehicle rental is reserved (see FIG. 185 (the “Total Loss”selection in the “Vehicle Condition” field of the Create Reservationscreen), sending the vehicle data to a third party valuation tool forprocessing, determining the valuation of the vehicle by a suitablemeasure such as actual cash value (ACV), sending the ACV to the system,using the search function to identify possible replacement vehiclesavailable for the customer (see FIG. 186), finalizing the replacementprocess with the customer including executing transfer of titledocumentation if desired, and posting the results of the vehiclereplacement in the system for access by the insurance adjuster so thathe can confirm that the customers claim has been satisfied. A flow chartdescribing this process is attached for further explanation (see FIG.187).

Various changes and modifications to the preferred embodiment asexplained herein would be envisioned by those of skill in the art.Examples of these changes and modifications include the utilization ofcomputer systems configured in any one of a myriad of ways using presenttechnology alone. For example, mobile computers are presently availableand wireless technology could be used to extend the integrated businessnetwork of the services provider, as well as match the mobility neededby the various users connected to and using the present invention. Theparticular software, and various aspects and features of its design,have been adapted for particular application to the vehicle rentalbusiness. Of course, computer software applications satisfying otherbusiness needs would necessarily require adaptation to their particularbusiness models. Thus, it is envisioned by the inventors herein that thevarious software programs described herein would be matched to theparticular business application to which the invention is utilized.These and other aspects of the preferred embodiment should not be viewedas limiting and instead be considered merely as illustrative of anexample of the practical implementation of the present invention. Thesechanges and modifications should be considered as part of the inventionand the invention should be considered as limited only by the scope ofthe claims appended hereto and their legal equivalents.

Exhibit A

See the file “Exhibit A.txt” submitted on the incorporated compact disc.

Exhibit B

See FIGS. 4-91.

Exhibit C

See the file “Exhibit C.txt” submitted on the incorporated compact disc.

Exhibit D

See the file “Exhibit D.txt” submitted on the incorporated compact disc.

Exhibit E ARMS Web 3.0 Functional Design Specification Extend RentalVersion 1.1 Extend Rental 1. Extend Rental Use Case 1.1 ApplicationOverview

-   -   The following is a document used to illustrate the process for        how the USER will extend a previously authorized rental using        ARMS/Web 3.0. The intent for this release of the ARMS/Web        application is to reach a much wider audience. This application        will target a Multi-Vendor, Multi-Segment, and International        customer base.

1.2 Brief Description

-   -   This use case will describe how the USER will extend a        previously authorized rental. The rental company (via an        Authorization Request), the RENTAL ADMINISTRATOR (via a Customer        Search), or Reporting (via the Callback feature) can initiate        this use case.

1.3 Use Case Actors

-   -   The following actors will interact with this use case:        -   RENTAL ADMINISTRATOR—The RENTAL ADMINISTRATOR will use the            system to extend a previously authorized rental. This use            case refers to a USER in the role of a rental administrator.            There are various types of customers that the USER would            represent, which include corporate account holders, car            dealerships, insurance companies, and others.        -   ARMS—The ARMS system will receive/send transactions to            ARMS/Web to confirm the extended rental.        -   RENTAL CAR COMPANY—A wide variety of rental car companies            will be able to use this system as well. Each company will            have the ability to initiate and manage their rentals            through the use of this application.

1.4 Pre-Conditions

-   -   The USER must have logged into the ARMS/Web system.    -   The USER must have selected a previously authorized, open        rental.

1.5 Flow of Events

-   -   The Flow of Events will include the necessary steps to make        changes and updates to “Extend Rental”.    -   1.5.1 Activity Diagram—see FIG. 92.    -   1.5.2 Basic Flow        -   1. The system will display the details of the Rental.        -   2. The USER will enter the number of days to extend the            rental.        -   3. The USER will submit the Extended Rental Details.        -   4. The system will validate the number of days the rental            will be extended.        -   5. The system will update the ARMS/Web database with the            Extend Rental Details.        -   6. The system will read the profile for the confirmation            screen setting.        -   7. For non-Enterprise rentals, the extension is sent to the            non-ERAC rental car company's rental system.        -   8. This ends the use case.    -   1.5.3 Alternative Flows        -   1.5.3.1 View Rental Notebook            -   At step 1 of the basic flow, the USER may choose to view                the history of a rental. The USER will be able to see                the diary notes associated with the Reservation/Rental.        -   1.5.3.2 Display Confirmation            -   After step 7, the USER may wish to have a confirmation                page displayed, indicating that some type of change has                taken place. The confirmation page is completely                optional; therefore, at anytime the USER wants to set                their profile to bypass this screen, he/she may do so.        -   1.5.3.3 Update USER Profile            -   During the confirmation process, the USER has the option                of changing their profile setting to display or hide the                confirmation page. Each time the setting is changed, the                USER profile must be updated to reflect the new                requirements set by the USER.        -   1.5.3.4 Validate Changes            -   If the USER changes or adds information, which does not                pass validation, an error message will notify the USER                and return them to step 1 of the Basic Flow.            -   If an error is discovered in the validation of the                reservation/rental information submitted by the USER,                the system would present the USER with an error message                and return them to the Detailed Reservation/Rental                Display. If the error is specific to a data field within                the form, the field should be highlighted and the error                described.        -   1.5.3.5 Change Customer File            -   Prior to step 3, the USER has the option to make changes                to the customer file. After clicking the change/add                link, the screen will refresh with all editable fields                opened and available for the USER to make changes.        -   1.5.3.6 Update ARMS/Web Database            -   After successfully validating the recent changes, the                system must update the ARMS/Web Database. The system                goes through the same process as in the Basic Flow, as                the database is updated to reflect the latest changes.

1.6 Post-Conditions

-   -   If the use case was successful then the rental has been extended        and the ARMS/Web system has been notified.    -   If the use case was unsuccessful then the system has remained        unchanged.

1.7 Special Requirements

-   -   The number of days to extend a rental must be an integer greater        than zero.    -   If a USER attempts to extend an insured rental beyond their        limits for number of days and dollar amount, the system should        return an error message.

1.8 Extension Points

-   -   1.8.1 MA-16 Reassign USER/Office (Transfer)        -   After the extend rental detail is displayed, the USER may            choose to transfer the current office/USER. First, the USER            would select to change the current office/USER. Second, the            system would display a list of authorized offices/USERs.            Third, the USER would select a new office/USER. If            additional changes are made to the customer file, the new            data will also be passed through the transfer process.    -   1.8.2 MA-08 View Car Class        -   The View Car Class use case will be used to allow the USER            to view details about and select a car class to apply to a            reservation. Details will include the average number of            passengers and luggage items that can be served by a vehicle            in the specific car class. The car class selected by the            USER should be applied to the reservation.    -   1.8.3 MA-15 Terminate Rental        -   After the extend rental detail is displayed, the USER may            choose to terminate the rental. If termination is selected,            the USER must enter a reason for the termination of the            rental. Termination means the insurance company is no longer            willing to pay for the rental.    -   1.8.4 MA-04 Send Message        -   The Send Message will be used to allow the USER to capture            messages and diary notes associated with extending a rental.            The USER can elect to either have the message sent to the            rental company responsible for the            reservation/authorization, or (Depending on the user segment            if this option is available) to store the note in the            ARMS/Web system without sending the message to rental            company. All MESSAGES and DIARY NOTES captured must be            related to a specific reservation/authorization.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Extend Rental Detail

-   -   This screen (see FIGS. 93( a)-(e)) will allow the USER to pick        which functions that he/she may want to change.    -   2.1.1 Screen Layout—Extend Rental Detail—see FIGS. 93( a)-(e)    -   2.1.3 Extend Rental Detail

Screen Specific Screen Label Type Size Screen Field Name Data Field NameRule Additional Output 15 Additional Charges Charges Handling For:Output 30 Handling for First Name + Last Last Name + First Adjuster'sName Name Name Note to Self Input 50 Message NOTE Only Messages: Output8 Message Creation Add Date N/A. Date Note to Input 50 Message Text NOTEN/A. Enterprise: Output 50 Message Text NOTE N/A. Claim Number: Output11 Claim Number Insurance Claim Purchase Purchase Order Number, PO#, CC#Order Number Number Corporate Corporate Class Class Number Number DaysOutput 2 Number of Days Number of Days N/A. Authorized to AuthorizedAuthorized Date:   additional Output 2 Number of Days to Number of Daysto authorized Extend Extend days Policy Limits List Box 5 Policy Maximumand Max $ Covered + Dollars per day Dollars Per Day Covered Output 30Rental Location Rental Location Branch Name days @: List Box 6 RentalLocation Rate Vehicle Rate N/A. Date of Rental Output 10 Rental StartDate Start Date N/A. Insured Name: Output 30 Insured's Name First Name +Last Name Output 30 Rental Location Address Line + N/A. Address AddressLine2 Output 25 Rental Location City City N/A. Name Output 10 RentalLocation Zip Code N/A. Postal/Zip Code Output 3 Rental Location State/State N/A. Province Code Output 13 Rental Location Telephone Number N/A.Telephone Number Date of Loss: Output 10 Date of Loss Date of LossOutput 20 Renter City Name City Output 10 Rental Postal/Zip Zip CodeCode Output 3 Renter State/ State Province Code Output 30 Renter StreetAddress Line Address Home: Output 16 Renter's Home Renters Night Phone +Not editable if ticket Phone Renters Night is Open. Phone ExtensionOutput 30 Renter's Name First Name + Last Will not be editable if Nameticket is open. First Name + Last Name Renter Output 30 Renter's NameFirst Name + Last N/A. Information: Name Work Phone: Output 16 Renter'sWork Phone Day Phone + Will not be able to Renters Day Phone edit ifticket is Open. Extension Owner's Output 4 Vehicle Year, Make RenterMake/Model + vehicle: and Model Renter Vehicle Year Repair Facility:Output 20 Body Shop Name Repair Facility Name Input 16 Body Shop PhoneTelephone Number Number Output 15 Repair Facility City City Output 3Repair Facility State State Output 7 Repair Facility zip Zip Code codeLast Day Output 10 Date rental is CALCULATED Calculated field.authorized authorized through Populated with an Open Ticket only.Charges to Output 10 Total Charges CALCULATED Date: Renter Type Output10 Claim type claim type description Claims Office: Output 3 Office Idexternal organization N/A. abbreviated name Vehicle Output 15 Type ofLoss loss type description Condition Renter Email: Output 20 Renter'sEmail renter email Will not be able to edit if ticket is Open.

-   -   2.1.4 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.4.1 Skip            -   When clicked, the USER will be taken out of the use case                without changing the current status of the request. Any                changes made by clicking Change or Add and keying data                in the bottom section will be saved.        -   2.1.4.2 Process            -   When clicked, the system will validate the input and                accept the changes made to the customer file. The                ARMS/Web database will be updated. The use case will                then end and the USER will return to the process from                which they came.        -   2.1.4.3 Notebook            -   When clicked, the USER will be taken to the Note Book                section at the bottom of the screen to view all messages                for this rental.        -   2.1.4.4 Set Last Date            -   When clicked, the system will terminate the rental. The                USER will be prompted to enter a termination date for                this rental. This coincides with the use case                MA-17—Terminate Rental.        -   2.1.4.5 Transfer File            -   When clicked, the USER will be taken to the Transfer                File screen. This screen allows the USER to change the                office or adjuster currently assigned to the customer                file. The required information in the Extend                Rental/Customer File will be passed to the Transfer File                screen. Upon completion of the transfer, the USER will                then be returned to the next action item or the profiled                start page, depending on the screen from which the USER                began.        -   2.1.4.6 Change or Add            -   When clicked, the system will refresh the current screen                and make all editable fields in the bottom section                (outside the gray box area) input capable. The changes                on the top of the screen will not be lost.        -   2.1.4.7 Top of page            -   When clicked, the USER will be taken to the top of the                current page.        -   2.1.4.8 View Car Class            -   When clicked, the USER will be taken to the View Car                Class Use Case. No changes will be lost. Once the USER                is finished with this use case, the USER will return to                the Extend Rental Use Case.        -   2.1.4.9 Extend Rental            -   When clicked, the system will validate the input and                accept the extension AND the changes made to the                customer file. The ARMS/Web database will be updated.                The use case will then end and the USER will return to                the process from which they came.

ARMS Web 3.0 Functional Design Specification Review List—Action ItemsVersion 1.1 Review List—Action Items 1. Review List Action Items UseCase 1.1 Application Overview

-   -   The following is a document used to illustrate the process for        how the USER would view and/or select any outstanding action        items assigned to them using ARMS/Web 3.0. The intent for this        release of the ARMS/Web application is to reach a much wider        audience. This application will target a Multi-Vendor,        Multi-Segment, and International customer base.

1.2 Brief Description

-   -   This use case describes how the USER would view and/or select        any outstanding action items assigned to them.

1.3 Use Case Actors

-   -   The following actors will interact with this use case.        -   RENTAL ADMINISTRATOR—The RENTAL ADMINISTRATOR will use the            system to review outstanding action items to be completed.            This use case refers to a USER in the role of a USER. There            are various types of customers that the USER would            represent, which include corporate account holders, car            dealerships, insurance companies, and others.        -   ARMS—The ARMS system will receive/send transactions to            ARMS/Web based on actions of the USER, retrieving and acting            action items.        -   RENTAL CAR COMPANY—A wide variety of rental car companies            will be able to use this system as well. Each company will            have the ability to initiate and manage their rentals            through the use of this application.

1.4 Pre-Conditions

-   -   The USER must be logged into the ARMS/Web system.    -   The USER must have selected to Review a List of Action Items.    -   The system must retrieve and confirm the USER ID and access        authority.

1.5 Flow of Events

-   -   The Flow of Events will include the necessary steps for a USER        to review and assign outstanding action items.    -   1.5.1 Activity Diagram—see FIG. 94.    -   1.5.2 Basic Flow        -   1. The USER selects to review the outstanding action items            list.        -   2. The system retrieves the list of outstanding action items            associated with the USER ID.        -   3. The system sorts and builds the list based on the            appropriate USER profile.        -   4. The system will display a list of all outstanding action            items assigned to the USER, which could include:            -   Authorize a Request            -   Extend a Rental            -   Handle Unapproved Invoices/Pay Approved Invoices            -   Send a Message        -   5. The USER will select an item from the action items list.        -   6. The system displays the detail appropriate to the action            item status.        -   7. Upon completion of the selected action item, the system            will determine the next action item and display until the            current list has been completed.        -   8. This ends the use case.    -   1.5.3 Alternative Flows        -   1.5.3.1 Handle For A Different USER            -   Until step 5, the USER may choose to handle requests for                another USER. At this time, the USER must select the                appropriate USER to handle for. The system will then                validate the ID of the alternate USER, and then rebuild                the action list to include all outstanding items                associated with the new ID.        -   1.5.3.2 Re-sort Action Items List            -   After displaying the action item list using the default                from the profile, the USER may decide to sort the list                based on some other criteria. At any time, the USER may                choose to re-sort the action item list (Depending on the                USER segment) based on Item Type, Date Received,                Renter's Name, Claim Number or Corporate Class Number or                Purchase Order Number, Rental Company, and                Administrator.        -   1.5.3.3 No Items Found            -   If there are no Action Items available for the USER work                on, the system will display a message indicating that                there are no available action items to display.

1.6 Post-Conditions

-   -   None

1.7 Special Requirements

-   -   1.7.1 Sort Request        -   The default sort order has been specified by the USERs            profile, which governs the order in which action items have            been presented. If invoices have been added to the USER's            payment list, a link displays for them to proceed to the            ‘Payment List’. Alternatively, after the last invoice has            been approved, the system automatically proceeds to the            ‘Payment List’ before resuming the outstanding action items.            If the USER has been designated with the responsibility of            handling the ‘Unassigned Requests,’ a link at the bottom of            the action item list displays.

1.8 Extension Points

-   -   An extension point indicates a link between this use case and        another use case. Extension points associated with the use case        are indicated below. Clicking on the extension point will open        the related use case.    -   1.8.1 MA-12—Extend Rental        -   At step 5, the USER must select an action item to perform.            At this point, the USER may elect to extend a previously            authorized rental. Extensions may be performed due to            prolonged body shop delays and other scenarios. Upon            completion of the Extend Rental process, the USER should be            returned to step 5 of the Basic Flow. The action item that            called for the extension should no longer appear in the            USER's action item list.    -   1.8.2 MA-10—Authorize Request        -   At step 5, the USER must select an action item to perform.            At this point, the USER may elect to authorize a direct bill            request. Upon completion of the authorization, the USER            should be returned back to step 5 of the Basic Flow. The            request needing authorization should no longer appear in the            USER's action item list.    -   1.8.3 Invoicing—BI-01—Handle Unapproved Invoices & BI-02 Pay        Approved Invoices & BI-03 Reject an Invoice        -   At step 5, the USER must select an action item to perform.            At this point, the USER may elect to pay approved invoices,            handle unapproved invoices, or reject an invoice. Upon            completion of this process, the USER should be returned back            to step 5 of the Basic Flow. The invoices that were            processed should no longer appear in the USER's action item            list.    -   1.8.4 MA-19—View Customer File (Message)        -   At step 5, the USER must select an action item to perform.            At this point, the USER may elect to view a message from the            rental company. Upon completion of the message, the USER            should be returned back to step 5 of the Basic Flow. The            message should no longer appear in the USER's action item            list.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Action Items

-   -   This screen (see FIGS. 95( a)-(e)) will allow the USER to pick        which functions that he/she may want to change.    -   2.1.1 Screen Layout—Action Items—see FIGS. 95( a)-(e)    -   2.1.2 Action Items—Summary

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleDate Received Output 0 Date Received action item assigned N/A. date TypeOutput 15 Action Item Type action item type N/A. description USER Output0 USER's Name First Name + Last N/A. Name Handling For: List Box 30Handling for USER's First Name + Last N/A. Name Name Welcome Back Output30 User's Name First Name + Last N/A. Name Claim Number Output 0 ClaimNumber Insurance Claim N/A. Purchase Purchase Order Number, PO#, CC#Order Number Number Corporate Corporate Class Class Number NumberRenter's Name Output 30 Renter's Name First Name + Last N/A. Name ClaimsOffice: List Box 3 Office external organization abbreviated name

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Renter's Name            -   When clicked on a specific hyperlink under the “Renter's                Name” heading, the USER will go into the details of that                particular action item and will begin any of the                following use cases:                -   MA-12—Extend Rental                -   MA-10—Authorize Request                -   Invoicing—BI-01—Handle Unapproved Invoices &                    BI-02—Pay Approved Invoices & BI-03 Reject an                    Invoice                -   MA-19—Customer File (Message)

ARMS Web 3.0 Functional Design Specification Assign a Request Version1.1 Assign a Request 1. Assign a Request Use Case 1.1 ApplicationOverview

-   -   The following is a document used to illustrate the process for        assigning the unassigned authorization requests to the        appropriate user. The assignments will be made using the ARMS        Web 3.0 system. The intent for this release of the ARMS Web        application is to reach a much wider audience. This application        will target a Multi-Vendor, Multi-Segment, and International        customer base.

1.2 Brief Description

-   -   This use case describes the process of how a USER will review        unassigned authorization request and assign them to a USER for        further handling.

1.3 Use Case Actors

-   -   The following actors will interact with this use case:        -   RENTAL ADMINISTRATOR—RENTAL ADMINISTRATOR will use the            system to assign the unassigned authorization requests. This            use case refers to a USER in the role of a rental            administrator. There are various types of customers that the            rental administrator would represent, which include            corporate account holders, car dealerships, insurance            companies, and others.        -   ARMS—The ARMS system will receive/send transactions to ARMS            Web to manage each phase of the rental process.        -   RENTAL CAR COMPANY—A wide variety of rental car companies            will be able to use this system as well. Each company will            have the ability to initiate and manage their rentals            through the use of this application.

1.4 Pre-Conditions

-   -   The USER must be signed-on to the ARMS Web system.    -   The USER should be authorized to assign a request.    -   If there are unassigned requests present, the USER has selected        the link from the Review List Action Items Use Case to enter        this use case.

1.5 Flow of Events

-   -   The Flow of Events will include the necessary steps to make        changes and updates to “Assign an Action Item”.    -   1.5.1 Activity Diagram—see FIG. 96.    -   1.5.2 Basic Flow        -   1. The USER selects the unassigned authorizations link.        -   2. The system retrieves all unassigned request summaries.        -   3. The system retrieves all OFFICE IDs within ARMS Web.        -   4. The system retrieves all USER IDs within the OFFICE.        -   5. The system displays the unassigned authorization            summaries with the offices and users.        -   6. The USER selects a user to assign to the request.        -   7. The system will update the ARMS Web database.        -   8. This ends the use case.    -   1.5.3 Alternative Flows        -   1.5.3.1 Cancel Use Case            -   The USER should be capable of leaving the use case at                any point prior to assigning the of the reservation                information.        -   1.5.3.2 Modify a Request            -   Before step 6 of the basic flow, the USER should be able                to make changes to the authorization.        -   1.5.3.3 Select a different office            -   Before step 6 of the basic flow, the USER should be able                to select a different office for this authorization                request. If a different office has been selected, the                user cannot assign the file to a new user. The new                office must now assign the file.

1.6 Post-Conditions

-   -   If the use case is successful, the system will change the        request type from an unassigned authorization request to direct        bill. If the user has authority to authorize this request, the        system will change the request to Authorized status and assign        the adjuster picked in Step 5 of the basic flow.    -   If the use case is unsuccessful, the system state will remain        unchanged.

1.7 Special Requirements

-   -   None

1.8 Extension Points

-   -   1.8.1 MA-04 Send Message        -   The Send Message function will be used to allow the user to            capture messages and diary notes associated with a rental            reservation/authorization. The USER can elect to have the            message sent to the rental branch location responsible for            the reservation/authorization. The USER may also send a            message without assigning the file to a user/office. All            MESSAGES and DIARY NOTES captured must be related to a            specific reservation/authorization.    -   1.8.2 MA-10 Authorize a Request        -   The USER may decide to enter into the full detail screen of            the unassigned request, which would invoke the Authorize a            Request use case.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Action Items—Unassigned

-   -   This screen (see FIGS. 97( a)-(e)) will allow the USER to assign        action items to an office or USER. The USER may also cancel an        item or change specified information in the Customer File        through this screen.    -   2.1.1 Screen Layout—Action Items—Unassigned (ARMS Web 2.0)—see        FIGS. 97( a)-(e)    -   2.1.2 Action Items—Unassigned

Screen Specific Screen Label Type Size Screen Field Name Data Field NameRule Claims Office: Output 3 Office Id external organization N/A.abbreviated name Handling For: Output 30 Handling for First Name + LastN/A. Adjuster's Name Name Output 30 Renter's Name First Name + Last Thisshould be a link. Name The USER should be able to get to the authorizepage from this screen field Output 30 Renter's Address Address LineOutput 10 Renter's City City Output 3 Renter's State State Output 10Renter's Zip Code Zip Code Output 16 Renter's Home Renters Night Phone +If these fields are Phone Renters Night populated, add a Phone Extensionlabel to the screen to differentiate between Home Phone and Work PhoneOutput 16 Renter's Work Phone Day Phone + If these fields are RentersDay Phone populated, add a Extension label to the screen todifferentiate between Home Phone and Work Phone Claim Number Input 30Claim Number Insurance Claim N/A. Purchase Purchase Order Number, PO#,CC# Order Number Number Corporate Corporate Class Class Number NumberVehicle List Box 15 Loss Type loss type description Condition Claim TypeList Box 15 Claim Type Rental type N/A. Bill Type Bill Type descriptionDate of Loss: Input 10 Date of Loss Date of Loss N/A. Note to Input 30Message Text NOTE N/A. Enterprise Assign to List Box 5 Office Idexternal organization office: abbreviated name Assign List Box 30Adjuster Name First Name + Last Lists only those adjuster: Nameadjusters the USER has authority to assign

Screen Function Definition

-   -   This section includes the definitions for all functions that can        be performed within the screen. This includes operations invoked        by button clicks, specific shortcut keystrokes, or other actor        activity.        -   2.1.2.1 <<Previous            -   When clicked, the USER will be taken back to the                previous screen.        -   2.1.2.2 Process            -   When clicked, the USER will be taken to the next item in                the action item list or a detail of the completed action                items. This button ends the use case.        -   2.1.2.3 Cancel            -   When clicked, the USER will be allowed to cancel the                authorization. If this occurs, the rental becomes                unauthorized and the rental is no longer responsibility                of the company.

ARMS/Web 3.0 Functional Design Specification View Car Class Version 1.3View Car Class 1. View Car Class Use Case 1.1 Application Overview

-   -   The following is a document used to illustrate the process for        how the USER would view examples of automobiles that are part of        each rental company car class using ARMS/Web 3.0. The intent for        this release of the ARMS/Web application is to reach a much        wider audience. This application will target a Multi-Vendor,        Multi-Segment, and International customer base.

1.2 Brief Description

-   -   This use case will allow the USER to view examples of        automobiles that are part of each rental company car class. The        USER will have the ability to select a car class and have the        rate for the car class apply to the reservation/authorization.

1.3 Use Case Actors

-   -   The following actors will interact with this use case:        -   RENTAL ADMINISTRATOR—The RENTAL ADMINISTRATOR will use the            system to view and/or select the car class that will apply            to a reservation. This use case refers to a USER in the role            of a USER. There are various types of customers that the            USER would represent, which include corporate account            holders, car dealerships, insurance companies, and others.        -   ARMS—The ARMS system will receive/send transactions to            ARMS/Web to retrieving information regarding the            automobiles.        -   RENTAL CAR COMPANY—A wide variety of rental car companies            will be able to use this system as well. Each company will            have the ability to initiate and manage their rentals            through the use of this application.

1.4 Pre-Conditions

-   -   The USER must be signed-on to the ARMS/Web system.    -   The USER must have a reservation or open ticket selected.

1.5 Flow of Events

-   -   The Flow of Events will include the necessary steps to view        and/or select the car class to apply to a rental reservation.    -   1.5.1 Activity Diagram—see FIG. 98.    -   1.5.2 Basic Flow        -   The Basic Flow of the View Car Class use case includes all            of the required steps to view and/or select a car class for            a rental reservation. If a car class is selected, it will be            used to populate rate information on a rental authorization.        -   1. The USER will select View Car Class from the active            reservation or open ticket.        -   2. The system will display a car class detail screen. If the            USER had previously selected a car class (for example, on            the Create Reservation screen), the car class selected will            be displayed. If no car class has been selected, the system            will display the Standard car class.        -   3. The USER will select the car class to apply to the            reservation or open ticket.        -   4. The system will return the USER to the active reservation            or open ticket and populate car class information based on            the car class selected.        -   5. This ends this use case.    -   1.5.3 Alternative Flows        -   1.5.3.1 Select Alternate Car Class            -   From Step 2 of the Basic Flow, the USER will have the                ability to view an alternate car class. The car classes                that will be available to view include:                -   Economy                -   Compact                -   Intermediate                -   Standard                -   Full Size                -   Premium            -   If the USER selects an alternate car class, the system                will refresh and present the details of the new car                class.        -   1.5.3.2 Populate Car Class Rates            -   If a rental branch location has already been selected                prior to entering this use case, the selection of a car                class will populate the rates that apply to the selected                car class on the active reservation or open ticket. This                alternate flow returns the USER to Step 4 of the Basic                Flow.

1.6 Post-Conditions

-   -   If successful, the selected Car Class will be returned to the        active reservation or open ticket.    -   If unsuccessful, the system state is unchanged.

1.7 Special Requirements

-   -   The additional requirements of the business use case are        included here. These are requirements not covered by the flow as        they have been described in the sections above.    -   1.7.1 Modify Car Class Selection Results        -   The USER may change the results of this use case as part of            the active reservation or open ticket.

1.8 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Car Class Detail Screen

-   -   This screen (see FIGS. 99( a)-(b)) will allow the USER to view        detailed information about the rental company's car classes. The        USER will also have the ability to select a car class to apply        to a rental reservation/authorization.    -   2.1.1 Screen Layout—see FIGS. 99( a)-(b)    -   2.1.2 Car Class Details

Screen Label Type Length Screen Field Name Data Field Screen SpecificRule Output 20 Car Class Name This should be the name of the currentlyselected car class. Output 40 Rental Company Name (Person Output 2 CarClass Person This should provide the Image) Capacity average personcapacity of the selected car class. (Luggage Output 2 Car Class LuggageThis should provide the Image) Capacity average luggage capacity of theselected car class. Hidden 255 Car Class Image This should provide aSource picture of an example car within the selected car class. Output120 Car Class Detail This should provide a Description description ofthe selected car class. Economy Output Economy Car Class This should bea hyperlink to the Economy car class detail. Compact Output Compact CarClass This should be a hyperlink to the Compact car class detail.Intermediate Output Intermediate Car This should be a hyperlink Class tothe Intermediate car class detail. Standard Output Standard Car ClassThis should be a hyperlink to the Standard car class detail. Full SizeOutput Full Size Car Class This should be a hyperlink to the Full Sizecar class detail. Premium Output Premium Car Class This should be ahyperlink to the Premium car class detail.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Select This Car Class            -   The continue screen function will allow the USER to                select the car class to apply to a reservation.            -   2.1.3.1.1 The Continue screen function is invoked                through either a button click or through an Enter                keystroke.        -   2.1.3.2 Previous            -   The Previous screen function allows the USER to return                to the previous screen.            -   2.1.3.2.1 The Previous screen function is invoked                through a button click.

3. Questions and Answers

-   -   None.

ARMS/Web 3.0 Functional Design Specification Authorize a Request Version1.1 Authorize a Request 1. Authorize Request Use Case 1.1 ApplicationOverview

-   -   The following is a document used to illustrate the process for        how a USER authorizes a direct bill request using ARMS/Web 3.0.        The intent for this release of the ARMS/Web application is to        reach a much wider audience. This application will target a        Multi-Vendor, Multi-Segment, and International customer base.

1.2 Brief Description

-   -   This use case describes how a USER authorizes a direct bill        request.

1.3 Use Case Actors

-   -   The following actors will interact with this use case:        -   RENTAL ADMINISTRATOR—The RENTAL ADMINISTRATOR will use the            system to authorize a direct bill request. This use case            refers to a USER in the role of a rental administrator.            There are various types of customers that the USER would            represent, which include corporate account holders, car            dealerships, insurance companies, and others.        -   ARMS—The ARMS system will receive/send transactions to            ARMS/Web to confirm the direct bill request.        -   RENTAL CAR COMPANY—A wide variety of rental car companies            will be able to use this system as well. Each company will            have the ability to initiate and manage their rentals            through the use of this application.

1.4 Pre-Conditions

-   -   The USER must be logged into the ARMS/Web system.    -   The USER must have the authority to authorize a request.    -   At least one outstanding unauthorized direct bill request must        be assigned that the USER may handle.    -   The USER must have selected an Unauthorized Direct Bill Request        from the Review Action Items Screen or from the Search Results        page.

1.5 Flow of Events

-   -   The Flow of Events will include the necessary steps to make        changes and updates to “Authorize Request”.    -   1.5.1 Activity Diagram—see FIG. 100.    -   1.5.2 Basic Flow        -   1. The USER selects an outstanding direct bill to authorize.        -   2. The system displays the Customer file.        -   3. The USER reviews the renter's information.        -   4. The USER inputs a number of Authorized Amounts, days and            required fields.        -   5. The USER submits the Authorization.        -   6. The system validates information in the Customer File.        -   7. If the USER assigned to the Customer File is ‘UNKNOWN’ or            ‘UNASSIGNED’, the System will assign the Customer File to            the current USER.        -   8. The system will update the ARMS/Web database with the            Authorization.        -   9. The System reads the USER profile to see if the            confirmation page should display.        -   10. If the profile indicates ‘Show Confirmation Page’, the            System will display the confirmation page.        -   11. For non-Enterprise rentals, the authorization request is            sent to the non-ERAC rental car company's rental system.        -   12. This ends the use case.    -   1.5.3 Alternative Flows        -   1.5.3.1 View Notebook            -   At step 3 of the Basic Flow, the USER can select to view                the transaction history (Notebook) by selecting the Go                To Notebook link.        -   1.5.3.2 Add Notes to Customer File            -   At step 3 of the Basic Flow, the USER can add notes to                the Customer File by typing in the appropriate notes                field on the Customer File page.        -   1.5.3.3 Skip Customer File            -   At step 3 of the Basic Flow, the USER can get out of the                Customer File by selecting the skip button on the                Customer File page.        -   1.5.3.4 Change Customer File            -   At step 3 of the Basic Flow, the USER can make changes                to the additional details of the Customer File. This is                done by selecting the Add/Change link which will invoke                an editable page with all *appropriate information                editable.

1.6 Post-Conditions

-   -   If the use case was successful then the changes should go into        effect immediately and the screen should revert back to the        original screen of entry.    -   If the use case was successful, then the ARMS/Web system will be        notified of authorization changes.    -   If the use case was unsuccessful then the system state will be        unchanged.

1.7 Special Requirements

-   -   1.7.1 Requirements for Claim Type Authorizations (Insurance        Users Only)        -   The following are a set of requirements surrounding the type            of authorized amounts that are allowable based on the Claim            Type associated with a rental. These restrictions DO NOT            APPLY to reservations that are submitted with a Direct            Billing Percentage of zero (0).        -   1.7.1.1 When the Claim Type selected is ‘Insured, ‘Theft’,            or ‘Uninsured Motorist’            -   1.7.1.1.1 For insurance USERs, the reservation/rental                must always include an Authorized Rate or both Policy                Daily and Maximum Limits as defined by the renter's                insurance policy. Zero (0) is an acceptable Policy Daily                Limit.            -   1.7.1.1.2 For insurance USERs, the reservation/rental                must include an Authorized Rate or Policy Daily Limit if                a Policy Maximum Limit is included. Zero (0) is an                acceptable Policy Daily Limit.        -   1.7.1.2 When the Claim Type selected is ‘Claimant’            (Insurance Users Only)            -   1.7.1.2.1 The reservation/rental must always include an                Authorized Rate.            -   1.7.1.2.2 The reservation/rental may not include a                Policy Daily/Maximum Limits selection.        -   1.7.1.3 Requirements for editable fields based on            reservation/ticket status            -   1.7.1.3.1 Depending on the status of the Customer File                the USER may change the following fields:

Unassigned/ Assigned but Field Name Unauthorized Unauthorized (Dependingon Reservation/ Reservation or Authorized USER Segment) Ticket TicketTicket CLAIM NUMBER X X X (Insurance & Fleet) PURCHASE ORDER NUMBER(Dealership) CORPORATE CLASS NUMBER (Corporate) CLAIM TYPE X X X(Insurance) BILL TYPE (Dealership) VEHICLE CONDITION X X X DATE OF LOSSX X X (Removed for corporate) INSURED X X X INFORMATION RENTER XINFORMATION DATE RENTAL X IS NEEDED NUMBER OF X X AUTHORIZED DAYS DIRECTBILL X X X PERCENT (Insurance Only) POLICY LIMITS X X X (Insurance andCorporate Only) AUTHORIZED RATE X X X

-   -   -   -   If the Customer File is an Unauthorized Reservation, the                USER can Reject the Authorization Request, Send a                Message, and/or Transfer (Assign) the file to a USER.            -   1.7.1.3.2 If the status of the Customer File is an open                ticket the following rules apply:

Unauthorized Authorized Reservation/ Authorized Actions ReservationTicket Open Ticket Send Message X X X Extension X Terminate Rental XCancel Authorization X X Transfer/Assign Adjuster X X X View Car Class XX X

1.8 Extension Points

-   -   An extension point indicates a link between this use case and        another use case. Extension points associated with the use case        are indicated below. Clicking on the extension point will open        the related use case.    -   1.8.1 MA-04 Send A Message        -   The Send Message will be used to allow the USER to capture            messages and diary notes associated with extending a rental.            The USER can elect to either have the message sent to the            rental company responsible for the            reservation/authorization, or (Depending on the USER segment            if this option is available) to store the note in the            ARMS/Web system without sending the message to rental            company. All MESSAGES and DIARY NOTES captured must be            related to a specific reservation/authorization.    -   1.8.2 MA-07 Additional Charges        -   The USER may choose to select the additional charges button            that displays a page showing all the additional items at the            branch with the branch charges displayed. The USER can            select the items and enter in the authorized amounts.    -   1.8.3 MA-16 Transfer Work        -   The USER may choose to transfer an authorization to a            different USER in his/her office or transfer the            authorization to another USER in a different office.    -   1.8.4 MA-08 View Car Class        -   The USER may choose to view the car class. This button            invokes the View Car Class use case.    -   1.8.5 MA-17 Cancel Authorization        -   The USER may choose to deny the authorization. When the USER            selects the CANCEL button, it will invoke the Cancel            Authorization use case to reject the authorization.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Authorize Rental Detail

-   -   This screen (see FIGS. 101( a)-(e)) will allow the USER to work        the currently selected authorization request. The USER        (Depending on the USER segment) may set the authorization        amounts and policy coverage limits or may assign the request to        another USER.    -   2.1.1 Screen Layout—Authorize Rental Detail—see FIGS. 101(        a)-(e)    -   2.1.2 Authorize Rental Detail

Screen Label Type Size Screen Field Name Data Field Screen Specific RuleHandling For: List Box 30 Handling for USER's First Name + Name LastName Note to: Input 0 Message NOTE Notebook Output 50 Message NOTEOutput 8 Message Creation Add Date Date Message Output 50 Message TextNOTE Output 10 Notebook creation Add Date date Claim no Output 30 ClaimNumber Insurance Claim Claim number for an Corporate Class CorporateClass Number insurance USER no Purchase Number Corporate Class Order noPurchase Order number is for a Number corporate USER Purchase ordernumber is for a dealership USER Claim Number: Input 11 Claim NumberInsurance Claim Claim number for an Corporate Class Corporate ClassNumber insurance USER Number Number Corporate Class Purchase OrderPurchase Order number is for a Number Number corporate USER Purchaseorder number is for a dealership USER    days @ Input 4 Number of DaysNumber Of Authorized Days Authorized Direct Bill %: Input 6 PercentCovered Bill To % Only visible to insurance USER Policy: Daily List Box5 Policy Maximum and Dollars Per Day Only visible to insurancerate/Maximum Daily Rates Covered and fleet USERs. dollars: Policy: DailyList Box 5 Policy Maximum and Max $ Covered Only visible to insurancerate/Maximum Daily Rates and fleet USERs. dollars: Output 30 RentalLocation Rental Location Branch Name Date Rental List Box 10 RentalStart Date Start Date Needed: days @    List Box 6 Vehicle Rate VehicleRate Insured Name: Input 30 Insured's Name First Name + Last NameInsured Name: Output 20 Insured's Name First Name + Last Name Output 30Rental Location Address Line + Address Address Line2 Output 25 RentalLocation City City Name Output 10 Rental Location Postal/ Zip Code ZipCode Output 3 Rental Location State/ State Province Code Output 13Rental Location Telephone Telephone Number Number Date of Loss: List Box10 Date of Loss Date of Loss Remove for corporate USERs Date of LossOutput 10 Date of Loss Date of Loss Remove for corporate USERs Output 30Renter's Address Line Address Line Renter's Address Output 20 Renter'sCity City Output 3 Renter's State State/Province Code Output 15 Renter'sZip/Postal Zip Code Code Home Phone: Output 16 Renter's Home PhoneRenters Night This field is input if the Phone + ticket is not opened.It Renters Night will not be editable if the Phone ticket is open.Extension Authorize Direct Output 30 Renter's Name First Name + N/A.Bill: for Last Name Renter: Output 30 Renter's Name First Name + N/A.Last Name Output 16 Renter's Work Phone Day Phone + Renters Day PhoneExtension Owner's Vehicle Output 20 Vehicle Year, Make Renter Vehicleand Model Year + Renter Make/Model Output 15 Repair Facility City CityRepair Facility Output 20 Repair Facility Name Repair Facility NameOutput 3 Repair Facility State State Output 10 Repair Facility TelephoneTelephone Number Number Output 7 Repair Facility Zip Zip Code Code ClaimType: List Box 15 Claim Type claim type N/A. description Claims Office:Output 3 Office Id external N/A. organization abbreviated name VehicleCondition List Box 20 Loss Type loss type description Vehicle ConditionOutput 20 Type of Loss loss type description Input 20 Renter's Emailrenter email

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Skip            -   When clicked, the USER will be taken out of the use case                without changing the current status of the request. Any                changes made by clicking Change or Add and keying data                in the bottom section will be saved.        -   2.1.3.2 Process            -   When clicked, the system will validate the input and                accept the changes made to the customer file. The                ARMS/Web database will be updated. The use case will                then end and the USER will return to the process from                which they came.        -   2.1.3.3 Notebook            -   When clicked, the USER will be taken to the Note Book                section at the bottom of the screen to view all messages                for this rental.        -   2.1.3.4 Set Last Date            -   When clicked, the system will terminate the rental. The                USER will be prompted to enter a termination date for                this rental. This coincides with the use case                MA-17—Terminate Rental.        -   2.1.3.5 Transfer File            -   When clicked, the USER will be taken to the Transfer                File screen. This screen allows the USER to change the                office or USER currently assigned to the customer file.                The required information in the Extend Rental/Customer                File will be passed to the Transfer File screen. Upon                completion of the transfer, the USER will then be                returned to the next action item or the profiled start                page, depending on the screen from which the USER began.        -   2.1.3.6 Change or Add            -   When clicked, the system will refresh the current screen                and make all editable fields in the bottom section                (outside the gray box area) input capable. The changes                on the top of the screen will not be lost.        -   2.1.3.7 Top of page            -   When clicked, the USER will be taken to the top of the                current page.        -   2.1.3.8 View Car Class            -   When clicked, the USER will be taken to the View Car                Class Use Case. No changes will be lost. Once the USER                is finished with this use case, the USER will return to                the Extend Rental Use Case.

ARMS Web 3.0 Functional Design Specification Create Reservation Version1.4 Create Reservation 1. Create Reservation Use Case 1.1 ApplicationOverview

-   -   The following is a document used to illustrate the process for        creating a reservation using ARMS Web 3.0. The intent for this        release of the ARMS Web application is to reach a much wider        audience. This application will target a Multi-Vendor,        Multi-Segment, and International customer base.

1.2 Brief Description

-   -   This use case will describe how a USER would create a rental        reservation in the ARMS Web system. When creating a reservation,        the USER is also creating an authorization for payment. The USER        may also submit a reservation without authorizing payment.

1.3 Use Case Actors

-   -   The following actors will interact with this use case:        -   RENTAL ADMINISTRATOR—The RENTAL ADMINISTRATOR will use the            system to create an authorized reservation. This use case            refers to a USER in the role of a rental administrator.            There are various types of customers that the rental            administrator would represent, which include corporate            account holders, car dealerships, insurance companies, and            others.        -   ARMS—The ARMS system will receive/send transactions to ARMS            Web to confirm the extended rental.        -   RENTAL CAR COMPANY—A wide variety of rental car companies            will be able to use this system as well. Each company will            have the ability to initiate and manage their rentals            through the use of this application.

1.4 Pre-Conditions

-   -   The USER must be signed in to the ARMS Web system.    -   The USER must the authority to create a reservation.

1.5 Flow of Events

-   -   The Flow of Events includes all steps necessary to create a        reservation using the ARMS Web system.    -   1.5.1 Activity Diagram—see FIG. 102.    -   1.5.2 Basic Flow        -   The Basic Flow of the Create Reservation use case includes            all of the required steps for a new reservation to be            created in the ARMS Web system. Shadowed boxes in the            Activity Diagram indicate the Basic Flow.        -   1. The USER selects to create a reservation from the top            navigation menu.        -   2. The system prompts the USER to enter initial information            about the renter (Depending on the user segment):            -   Corporate Class Number or Claim Number (The use case                will refer to this as ‘Reference Number’)            -   Bill type            -   Renter First Name            -   Renter Last Name            -   Rental Company            -   Telephone Number or Postal Code where the renter would                like to be picked up        -   3. The USER enters initial information about the renter.        -   4. The USER submits the initial reservation information to            the system.        -   5. The system will validate the initial information entered            by the USER. (See section 1.5.3.1 Initial Reservation            Information Invalid in Alternative Flows on page 4 for            validation rules.)        -   6. The system will perform a search for previous            authorizations that may correlate directly to the rental            reservation that the USER is beginning to establish. The            system will search for two key types of records:            -   Unauthorized Request Matches            -   An Unauthorized Request is defined as a rental                Authorization Request that is generated when The Rental                Company creates a reservation or contract for the                customer that has not been approved. This search helps                to prevent the USER from creating a new reservation for                a customer that has an outstanding Unauthorized Request                in the ARMS system. The Unauthorized Request search is                completed using the first three characters of the Renter                Last Name and is limited to unauthorized requests                (requests in unassigned or direct bill request statuses)                for the selected Office. If matches are found, the                Unauthorized Request/Authorized Request Search Matches                Alternative Flow will be invoked.            -   Authorized Matches            -   Reference numbers that have already been associated with                a rental reservation or contract (i.e., Authorized                Rentals) should be brought to the attention of the USER                to help prevent over-authorization situations. The                system will search for an exact corporate class number                match on any reservation or ticket (open or closed)                related to the company in the last six months. This                search will be completed using the exact Reference                Number on all authorized requests (requests in any                status other than unassigned or direct bill request).        -   If no matching records are found, the Basic Flow continues.        -   7. The system will retrieve a rental branch location where            the rental is needed based on the Telephone Number or Postal            Code entered by the USER. If no allocation is found, a            message should be generated notifying the USER that no            location was available for the search criteria and that            Claims Connection will handle the reservation (include the            search criteria in message).        -   8. The system will retrieve the current applicable rates for            that rental branch location. If no rental branch location is            available, the system will display an open text box to allow            the USER to type in a rate.        -   9. The system will display the Quick Reservations screen.        -   10. The USER will enter the reservation information.        -   11. The USER submits the reservation to the system.        -   12. The system will validate the reservation information            submitted by the USER. (See section 1.5.3.3 Reservation            Information Invalid in Alternative Flows on page 5 for            validation rules.)        -   13. The system updates the database.        -   14. The system sends the reservation to ARMS.        -   15. The system will display the reservation confirmation to            the USER. The reservation confirmation will not include a            confirmation number, but will incorporate a message that The            Rental Company has received the reservation.        -   16. If the reservation is a non-Enterprise reservation, then            the transaction is electronically transmitted to the            intended rental car company's rental system.        -   17. This ends the use case.    -   1.5.3 Alternative Flows        -   The Alternative Flows of this use case can occur when            conditions exist or specific USER feedback is provided.        -   1.5.3.1 Initial Reservation Information Invalid            -   If the initial reservation information is invalid (Step                5 of the Basic Flow), the system should present an error                message to the USER and force the USER back into Step 2                of the Basic Flow.            -   1.5.3.1.1 It will be considered invalid if the Reference                Number, Renter First Name, Renter Last Name, Rental                Company, or Where Needed Value (Postal Code or Telephone                Number) have not been included.            -   1.5.3.1.2 It will be considered invalid if the ‘where                needed’ search criteria is a U.S. or Canadian telephone                number and the first three digits (i.e., area code) meet                the criteria below:                -   0XX                -   1XX                -   the second and third digits equal (e.g., 800, 877,                    888, etc.)            -   Where X equals any digit 0 through 9.            -   1.5.3.1.3 It will be considered invalid if the ‘where                needed’ search criteria is a U.S. or Canadian telephone                number that does not consist of 10 digits.            -   1.5.3.1.4 It will be considered invalid if the ‘where                needed’ search criteria is a U.S. postal code that does                not consist of 5 or 9 digits.            -   1.5.3.1.5 It will be considered invalid if the ‘where                needed’ search criteria is a Canadian postal code that                does not consist of 6 alphanumeric characters in the                format AXAXAX where A is an alpha character and X is a                digit between 0 and 9.        -   1.5.3.2 Unauthorized Request/Authorized Request Search            Matches            -   If either the search for Unauthorized Requests or the                search for Authorized Request matches returns a positive                result (Step 6 of the Basic Flow), the matching records                will be presented to the USER. The matching records                should be provided in summary form, and be distinctly                identified as either Authorized Request matches or                potential Unauthorized Request matches.                -   For Authorized Request matches, the USER will have                    the ability to select the Authorized Request and                    move into the MA-19 View Customer File use case to                    view the details of the previously authorized                    rental. The USER will have the option of continuing                    or canceling this use case from the MA-19 View                    Customer File use case.                -   For Unauthorized Request matches, the USER will have                    the ability to select the Unauthorized Request and                    move into the MA-10 Authorize Request use case to                    review and/or perform operations on the Unauthorized                    Request.            -   If the customer does not appear as an Unauthorized                Request or Corporate Class Number match, the USER can                select to continue to Step 7 of the Basic Flow.        -   1.5.3.3 Reservation Information Invalid            -   If an error is discovered in the validation of the                reservation information submitted by the USER (Step 12                of the Basic Flow), the system will present the USER                with an error message and return them to Step 9 of the                Basic Flow (NOTE: If the USER submitted information from                the Detailed Reservation screen, they should be returned                to the Display Detailed Reservation Alternative Flow                above). If the error is specific to a data field within                the form, the field should be highlighted and the error                described.            -   1.5.3.3.1 It will be considered invalid if the Reference                Number, Renter First Name, Renter Last Name, Vehicle                Condition, Rental Location, Authorized Number of Days,                and at least one Renter Telephone number have not been                included.            -   1.5.3.3.2 It will be considered invalid if the customer                has established Reference Number editing and the                Reference Number format does not meet the requirements                of the customer's Reference Number definition. Reference                Number definition is completed as part of the company                profile. (Claim Number format definition will be defined                in some cases in both the ARMS Web system and in the                ARMS/400 system (e.g., Nationwide, GEICO). Claim number                definition will have to be maintained in BOTH systems in                cases where this overlap exists. We are unable to reuse                the claim number format definitions due to technical                complications.)            -   1.5.3.3.3 It will be considered invalid if any field                identified as REQUIRED in the company/office profile is                not included.            -   1.5.3.3.4 It will be considered invalid if any data                entered violates the data type as specified by the ARMS                Web database (i.e., alpha characters in a numeric                field).            -   1.5.3.3.5 A warning will be presented to the USER if any                defined limits identified in the company/office/user                profile are exceeded (e.g., Maximum Number of Days                Authorized). The system will allow the USER to submit                the authorization from the warning.            -   1.5.3.3.6 It will be considered invalid if the                Authorized Number of Days is included and is less than                zero (0).            -   1.5.3.3.7 It will be considered invalid if the Date of                Loss is greater than the current date.            -   1.5.3.3.8 It will be considered invalid if the first                three digits (i.e., area code) of any U.S. or Canadian                telephone number meet the criteria below:                -   0XX                -   1XX                -   The second and third digits equal (e.g., 800, 877,                    888, etc.)            -   Where X equals any digit 0 through 9.            -   1.5.3.3.9 It will be considered invalid if a U.S. or                Canadian telephone number does not consist of 10 digits.            -   1.5.3.3.10 It will be considered invalid if a U.S.                postal code does not consist of 5 or 9 digits.            -   1.5.3.3.11 It will be considered invalid if a Canadian                postal code does not consist of 6 alphanumeric                characters in the format AXAXAX where A is an alpha                character and X id a digit between 0 and 9.            -   1.5.3.3.12 It will be considered invalid if an E-mail                address is included that does not include an ‘@’                character.        -   1.5.3.4 Cancel Use Case            -   The USER should be capable of canceling the use case at                any point prior to the submission of the reservation to                the ARMS Web database. The USER should be returned to                the previous activity/page that the USER was on prior to                entering this use case.

1.6 Post-Conditions

-   -   If successful, a reservation authorization is sent to ARMS.    -   If unsuccessful, the system state will be unchanged.

1.7 Special Requirements

-   -   1.7.1 Requirements for Reference Number Formatting        -   The following statements are a set of requirements for            providing custom reference number formatting for a customer.            The ARMS Web system will allow customer companies to define            a specific layout or format that they use as their standard            reference number format, so that the reference number field            used in the system is presented as separate fields and are            easily recognizable and ‘intuitive’ to the USER. These            requirements will be implemented to all system functions            where the customer reference number is used.        -   1.7.1.1 Customers must have the ability to define their            reference number format (and in some cases, validations on            specific portions of the reference number format) as part of            the company profile. More than one reference number format            can be stored per company, and each reference number format            definition must have a unique identifier/name. The selection            of which reference number format to use should be defined as            part of the office profile using the reference number format            unique identifier/name.        -   1.7.1.2 Reference numbers will be defined in ‘segments’.            Each segment will be presented to the USER as a separate            field. For example, if the reference number format for the            COMPANY were 45-A7456-1207, the reference number format            would be defined to the system as a 2-character numeric            field, a 5-character alphanumeric field, and a 4-character            numeric field.        -   1.7.1.3 Customers must have the ability to define a set of            ‘valid values’ for any given segment of the reference number            format. Valid Values allow the customer to dictate what the            valid entries for a given reference number segment would            include. For example, if the second segment in the            customer's reference number format must be a state            abbreviation, the customer could define valid values for            that segment as ‘AL’, ‘AR’, ‘AK’, etc. If the USER does not            enter one of the valid values, an error would be generated            to notify the USER to enter a ‘valid’ value. If no valid            values are included for a reference number segment, all            entry in to the field will be considered valid (assuming            that the data type is correct). If valid values are            specified, entry into the reference number segment MUST            MATCH ONE OF THE VALID VALUES IDENTIFIED.        -   1.7.1.4 The system will display the reference number            field(s) as it is described by the reference number format            definition for the office.    -   1.7.2 Requirements for Finding Rental Location        -   Below are the requirements for finding a rental location,            across multiple rental car companies, in the ARMS Web            system. ARMS Web will resolve a rental location and pass the            location to ARMS for routing (which is a deviation from            current state handling). These requirements were derived            from the current state business requirements for the ARMS            locator system.        -   1.7.2.1 ARMS Web will always return a Rental Company's            branch location for a reservation. For all ARMS Web            reservations, the following rules for finding a rental            location apply:            -   1.7.2.1.1 For United States locations, the locator will                search a 50-mile radius around the renter's phone number                or postal code for the closest branch that accepts ARMS                reservations.            -   1.7.2.1.2 For International locations, the locator will                search a 50-mile radius around the renter's phone number                or postal code for the closest open branch that accepts                ARMS reservations. If no open branches are found, the                closest branch that accepts ARMS reservations should be                returned.        -   1.7.2.2 When the rental branch location is determined, the            system will retrieve the name, shipping address, telephone            number and rates of the rental branch location and present            them to the USER on the Create Reservation screen(s).        -   1.7.2.3 The system will only display Claims            Connection (7680) as the location (with no rates) when no            location can be found within the 50-mile radius. If Claims            Connection is displayed, a message should be included to            indicate that no rental branch location was found within a            50-mile radius of the search criteria, and Claims Connection            will ensure that the reservation is handled appropriately.    -   1.7.3 Requirements for Routing a Reservation        -   When a reservation is submitted to the ARMS Web system,            routing of the reservation is required to ensure that the            renter is called within two hours to confirm rental details.            Routing is done AFTER the reservation has been submitted to            the ARMS Web system, and is transparent to the USER. The            reservation can be routed to the selected rental branch, to            Claims Connection, or to a regional call center based on the            following rules:        -   NOTE: These requirements were derived from the current state            business requirements for the ARMS locator system.        -   1.7.3.1 The system should automatically route submitted            reservations to Claims Connection between Friday 11:00 pm            and Sunday 11:00 pm, regardless of whether the selected            rental branch location is open or not.        -   1.7.3.2 The system should determine if the selected rental            branch location on a submitted reservation is open or            closed.            -   1.7.3.2.1 If the selected branch is open, the submitted                reservation should be routed directly to the rental                branch location (except in cases where a regional call                center exists, see 1.7.3.3 below).            -   1.7.3.2.2 If the selected rental branch location is                closed, the system will determine if the company that                submitted the reservation has established after-hours                handling of reservations. If the company has not                established after-hours handling, the reservation is                routed to the selected rental branch location (except in                cases where a regional call center exists, see 1.7.3.3                below). If the company has established after-hours                handling, the following rules apply:            -   1. The system will check the hours of availability for                Claims Connection. Claims Connections Hours are 5:00                a.m.-11:00 p.m. CST, 7 days a week. (Although we receive                reservations 24 hours/day, 7 days/week, we do not route                them between 11:45 pm and 4:30 am (CST). The only                exception to this is Saturday night to Sunday.)                -   a. If Claims connection is open, the reservation                    will be routed to Claims Connection. (The insurance                    company customer, National Marketing and the Claims                    Connection Manager will determine whether or not                    Claims Connection makes a courtesy call to the                    renter).                -   b. If Claims Connection is closed, the closest                    branch hours are checked to see if they will be open                    within 8 hours. If the branch will be open in 8                    hours, the reservation will be routed to the rental                    branch location (except in cases where a regional                    call center exists, see 1.7.3.3 below). If the                    branch will not be open in the next 8 hours, the                    reservation will be routed to Claims Connection.        -   1.7.3.3 The system should determine if the selected rental            branch location on a submitted reservation has a regional            call center.            -   1.7.3.3.1 If the selected rental branch location has a                call center to handle customer callbacks, the                reservation should be routed to the call center.            -   1.7.3.3.2 If the selected rental branch location does                not have a call center to handle customer callbacks, the                reservation should be routed to the rental branch                location.        -   1.7.3.4 The system should provide specific feedback            indicating the reason a reservation was re-routed when the            Authorization Confirmation is received. This will allow the            USER to be aware of the reason for the change of location if            they access the reservation while it is owned by someone            other than the rental branch location selected when the            reservation was originally submitted.            -   1.7.3.4.1 If the reservation is re-routed to Claims                Connection because the selected rental branch location                was closed, the system should provide a message (that                will be accessible through the diary notes/notebook)                that states the reservation was routed to Claims                Connection because the rental branch location was closed                when the reservation was submitted.            -   1.7.3.4.2 If the reservation is re-routed to a regional                call center to expedite the callback process, the system                should provide a message (that will be accessible                through the diary notes/notebook) that states the                reservation was routed to a regional call center to                expedite the renter callback process.        -   1.7.3.5 The system should include a message/note with the            group/branch number and address of the rental branch            location selected by the USER if the reservation is routed            to any location (i.e., Claims Connection or otherwise) other            than the rental branch location selected by the USER.    -   1.7.4 Maintenance of Source Systems        -   This use case requires that information in the existing            Locator and Special Instructions (AS/400) databases be kept            current and it is assumed that the group responsible for            maintaining these databases will continue to do so in the            future. Locator is used to retrieve Rental Branch Location            information, and Special Instructions is used to retrieve            rate information for a selected rental branch location.

1.8 Extension Points

-   -   An extension point indicates a link between this use case and        another use case. Extension points associated with the use case        are indicated below.    -   1.8.1 MA-10—Authorize Request        -   The Authorize Request use case will be used to allow the            USER to view and perform operations on an outstanding            Unauthorized Request. The USER will not be returned to this            use case on completion of the Authorize Request use case.    -   1.8.2 MA-19—View Customer File        -   The View Customer File use case will be used to allow the            USER to view the customer file when a matching authorized            request is found and selected. The USER will have the option            of ending the use case or be returned to Step 9 of the Basic            Flow on completion of the View Customer File use case.    -   1.8.3 MA-02—Find Rental Location        -   The Find Rental Location use case will be used to allow the            user to find one or more alternate rental branch locations            that can provide service to the customer. The USER should be            returned to Step 9 of the Basic Flow upon completion of the            Find Rental Location use case. If the USER selects a rental            branch location, branch information (i.e., address, phone)            should be returned and the appropriate fields should be            populated on the Reservation screen.    -   1.8.4 MA-04—Send Message        -   The Send Message use case will allow the USER to send a            message to the Rental Company branch regarding the            reservation, or select to store the message text with the            reservation as a diary note (which is not sent to the            branch). The USER should be returned to Step 9 of the Basic            Flow upon completion of the Send Message use case.    -   1.8.5 MA-07—Additional Charges        -   The Additional Charges use case will be used to add special            charges to the reservation being created by the USER. The            USER should be returned to Step 9 of the Basic Flow upon            completion of the Additional Charges use case. Any            Additional Charges captured should be returned and applied            to the reservation. The existence of Additional Charges            should be reflected on the reservation screen.    -   1.8.6 MA-08—View Car Classes        -   The View Car Classes use case will be used to allow the USER            to view details about and select a car class to apply to a            reservation. Details will include the average number of            passengers and luggage items that can be served by a vehicle            in the specific car class. The USER should be returned to            Step 9 of the Basic Flow upon completion of the View Car            Classes use case. The car class selected by the USER should            be applied to the reservation.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Initial Reservation Screen

-   -   The Initial Reservation screen provides the user interface and        functions to support Steps 2 through 4 of the Basic Flow. The        information captured on this screen will allow the system to        perform several background search activities, and help to better        construct the Quick/Detailed Reservation screen. All information        captured on the Initial Reservation screen is required to create        a new reservation, and is reused later in the reservation        creation process.    -   2.1.1 Screen Layout—see FIGS. 103( a)-(e)    -   2.1.2 Screen Field Definition

Screen Field Screen Label Type Size Name Data Field Screen Specific RuleRenter First Name Text 15 Renter First Name First Name Renter First Nameis a required field. Renter Last Name Text 20 Renter Last Name Last NameRenter Last Name is a required field. Claim Number Text 30 Claim NumberInsurance ‘Reference’ Number is a Purchase Order Purchase Order Claimrequired field. Number Number Number, PO#, ‘Reference’ number should beCorporate Class Corporate Class CC# presented in separate fields toNumber Number correspond to the reference number format (segments) thathas been defined by the USER profile. Insurance User - Claim NumberFleet User - Claim Number Dealership User - Purchase Order NumberCorporate User - Corporate Class Number Claim Type Combo 20 Rental TypeRental type The values of the Rental Type Bill Type Box Descriptiondescription field for the Insurance user class are: ‘Insured’,‘Claimant’, ‘Theft’ and ‘Uninsured’. The default value is ‘-Select ClaimType-’. Claim Type is a required field. Text 15 Where Needed Day Phoneor Where Needed Value is a Value Zip Code required field. Postal CodeRadio 1 Where Needed NOT If the Where Needed Postal Button Postal CodeSTORED Code Indicator is set, the Indicator Where Needed Value shouldpre-populate the Renter Zip/Postal Code on the Quick/DetailedReservation screen. Phone Radio 1 Where Needed NOT This should be thedefault Button Telephone STORED radio button selected. Indicator If theWhere Needed Telephone Indicator is set, the Where Needed Value shouldpre-populate the Renter Phone Number 1 on the Quick/Detailed Reservationscreen.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Create Reservation            -   The Create Reservation screen function will allow the                USER to submit the information on the Initial                Reservation screen and move on in the create reservation                process. The system will use this information to perform                background searches for Unauthorized Requests and                Corporate Class Number Matches, and to build the                Quick/Detailed Reservation screen appropriately.            -   2.1.3.1.1 The Create Reservation screen function is                invoked through either a button click or an Enter                keystroke.            -   2.1.3.1.2 The information captured on the Initial                Reservation screen will be used to pre-populate the                corresponding fields on the Quick/Detailed Reservation                screen.            -   2.1.3.1.3 If the information submitted to the ARMS Web                application is invalid or incomplete, this screen                function should prompt the USER with an error. The error                should be specific as to the cause of the failure. All                information previously entered should remain populated                in each field, with the problem field highlighted or                otherwise identified.

2.2 Authorization Matches Found Screen

-   -   The Authorization Matches Found screen provides the functions to        support the Unauthorized Request/Authorized Request Search        Matches alternative flow.    -   2.2.1 Screen Layout—see FIGS. 104( a)-(e)    -   2.2.2 Screen Field Definition

Screen Field Screen Label Type Size Name Data Field Screen Specific RuleHandling for: Output 35 User Name First Name + Should be presented asUser Last Name First Name + User Last Name Office Combo 10 OfficeLocation external The values presented in the Box organization OfficeLocation list should be abbreviated limited to the offices that the nameuser has been granted the authority to create a reservation. The defaultselection is the last selected office location. If the user has notselected an office, the default selection is the user's default officeas defined in the user profile. Office is a required field. Renter NameOutput 35 Renter Name First Name + Should be presented as Last Name‘Renter Last Name + “,” + Renter First Name’ Should provide a hyperlinkto the corresponding Authorize Request record (see MA-10 AuthorizeRequest use case). This field is in the “Unauthorized Request Matches”section of the “Authorization Matches Found” screen Claim Number Output30 Claim Number Insurance Should provide a hyperlink to Purchase OrderPurchase Order Claim the corresponding Number Number Number, PO#,Unauthorized Request record. Corporate Class Corporate Class CC# Thisfield is in the Number Number “Unauthorized Request Matches” section ofthe “Authorization Matches Found” screen. Insurance User - Claim NumberFleet User - Claim Number Dealership User - Purchase Order NumberCorporate User - Corporate Class Number Status Output 15 AuthorizationStatus This field is in the Status Description “Unauthorized RequestMatches” section of the “Authorization Matches Found” screen. RenterName Output 20 Renter Name First Name + Should be presented as Last NameRenter Last Name + Renter First Name Should provide a hyperlink to thecorresponding Customer File. This field is in the “Authorized RequestMatches” section of the “Authorization Matches Found” screen. ClaimNumber Output 30 Claim Number Insurance Should provide a hyperlink toPurchase Order Purchase Order Claim the corresponding Customer NumberNumber Number, PO#, File. Corporate Class Corporate Class CC# This fieldis in the “Reference Number Number Number Matches” section of the“Authorization Matches Found” screen. Insurance User - Claim NumberFleet User - Claim Number Dealership User - Purchase Order NumberCorporate User - Corporate Class Number Claim Type Output 20 Rental TypeRental type This field is in the “Reference Bill Type Descriptiondescription Number Matches” section of the “Authorization Matches Found”screen. Insurance User - Claim Type Fleet User - Claim Type DealershipUser - Bill Type Status Output Authorization Status This field is in the“Reference Status Description Number Matches” section of the“Authorization Matches Found” screen. Authorized Output 9 AuthorizedTotal CALCULATED This field is in the “Reference Amount Amount NumberMatches” section of the “Authorization Matches Found” screen.

-   -   2.2.4 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.2.3.1 New Reservation            -   The New Reservation screen function button will allow                the USER to close/continue beyond the Authorization                Matches Found screen.            -   2.2.3.1.1 The New Reservation screen function is invoked                through either a button click or through an Enter                keystroke.

2.3 Quick Reservation Screen

-   -   The Quick Reservation screen provides support for Step 9 of the        Basic Flow.    -   IMPORTANT NOTE: This is the minimum allowable set of fields on        the Quick Reservation screen. The Quick Reservation screen will        also include any fields indicated as QUICK RESERVATION in the        company/office profile! See the Detail Reservation screen for        all available fields.    -   2.3.1 Screen Layout see FIGS. 105( a)-(e)    -   2.3.2 Screen Field Definition

Screen Field Screen Label Type Size Name Data Field Screen Specific RuleOutput 35 User Name First Name + Should be presented as User Last NameFirst Name + User Last Name Office Combo 10 Office Location external Thedefault value should be Box organization the primary office of theidentifier current user. The values presented in the Office Locationlist should be limited to the offices that the user has been granted theauthority to create a reservation. If changed, the system shouldautomatically refresh the screen and update the “Handling for” list tothe users in the newly selected office with the ability to create areservation. Handling for Combo 35 Handling for First Name + The combolist should include Box Last Name the users for the selected officelocation that have the authority to create a reservation. The defaultvalue should be ‘Yourself’. The handling for users should be presentedas User Last Name + User First Name in alphabetical order. Claim NumberText Box 30 Claim Number Insurance Should be populated by the PurchaseOrder Purchase Order Claim Reference Number entered Number NumberNumber, PO#, on the Initial Reservation Corporate Class Corporate ClassCC# screen. Number Number Reference number should be presented inseparate fields to correspond to the claim number format (segments) thathas been defined by the USER profile. If changed, the system shouldvalidate that no matching reference numbers exist (i.e., referencenumber matching). The user should be notified if a match exists.Reference Number is a required field. Insurance User - Claim NumberFleet User - Claim Number Dealership User - Purchase Order NumberCorporate User - Corporate Class Number Claim Type Combo 20 Rental TypeRental type Should be populated by the Bill Type Box Descriptiondescription Rental Type selected on the Initial Reservation screen. Thevalues of the Rental Type field for the Insurance user class are:‘Insured’, ‘Claimant’, ‘Theft’, and ‘Uninsured’. Claim Type is arequired field. Vehicle Condition Combo 20 Vehicle Condition DriveableFlag + The values of the Vehicle Box Repairable Condition field shouldinclude: Flag ‘Driveable’, ‘Non-Driveable’, and ‘Total Loss’. thedefault value should be ‘-Select Vehicle Condition-’. Renter First NameText 15 Renter First Name First Name Should be populated by the RenterFirst Name entered on the Initial Reservation screen. If the RenterFirst Name changes, and an exact/ Unauthorized request match exists onthe Renter First Name + Renter Last Name combination, the user will benotified of this match. Renter First Name is a required field. RenterLast Name Text 20 Renter Last Name Last Name Should be populated by theRenter Last Name entered on the Initial Reservation screen. If theRenter Last Name changes, and an exact/ Unauthorized request matchexists on the Renter First Name + Renter Last Name combination, the userwill be notified of this match. Renter Last Name is a required field.Combo 10 Renter Phone Type 1 The combo list should include Box thevalues: ‘Home’, ‘Work’, ‘Mobile’, and ‘Pager’. The default value shouldbe ‘Select Type’ Text 15 Renter Phone Day Phone If the Where Neededcriteria Number 1 entered on the Initial Reservation or Find a RentalLocation screen was ‘Telephone’, the Where Needed Value from the screenshould be populated in this field. At least one renter phone number isrequired. Text 5 Renter Phone Renters Day N/A Extension 1 PhoneExtension Post Code Text 10 Renter Postal Code Zip Code If the WhereNeeded criterion entered on the Initial Reservation or Find a RentalLocation screen was ‘Postal Code’, the Where Needed Value from thescreen should be populated in this field. Email address Text Box 50email Address N/A Send email Check 1 email Confirmation This field willdefault to confirmation to Box Indicator unchecked. the renterAuthorized Days Text 3 Authorized Number Number Of The Number of Days isa of Days Days required field. Authorized Policy Limits Combo 10 PolicyDaily Limit Dollars Per The combo list should include Box and Policy DayCovered + the policy daily and maximum Maximum Max $ limits as definedin the Covered company/office profile. The policy limits should bepresented as ‘Policy Daily Limit + “/” + Policy Maximum Limit’. Thisfield should default to ‘Select Policy Limits’ if the Claim Type is‘Insured’, ‘Uninsured Motorist’, or ‘Theft’ If the Claim Type is‘Claimant’, this field should NOT be displayed. ‘Other’ should be aselection in the list of options. If selected, the system willautomatically replace the combo box with an open text box to allow theUSER to type in a Daily Policy Limit, and a second open text box toallow the USER to type in a Maximum Policy Limit. Combo 20 AuthorizedRate Vehicle Rate This field should be a combo Box box that lists all ofthe rates and car classes for the rental branch location in the format‘Rate + “” + Car Class’ ‘Other’ should be a selection in the list ofoptions. If selected, the system will automatically replace the combobox with an open text box to allow the USER to type in a rate. A combobox should also be included that allows the USER to select a car classwith selections to include ‘Economy’, ‘Compact’, ‘Intermediate’,‘Standard’, and ‘Full Size’. If the reservation is for an ‘Insured’,‘Uninsured’, or ‘Theft’ Claim Type, the default selection for the fieldshould be ‘-Policy Limits-’ If the reservation is for a ‘Claimant’ ClaimType, the default selection for the field should be ‘-Select a rate-’.Additional Charge Output Additional Charges Should include theAdditional Charge Description, the Additional Charge Value, and theAdditional Charge Type. More than one additional charge can exist.Direct Billing % Text 3 Authorized Direct Bill To % The Direct Bill %should Bill Percent default to 100%. The Direct Bill % is a requiredfield. Authorized Total Output 9 Authorized Total CALCULATED Theauthorized total amount Amount Amount field should show the total amount(w/o taxes and gov't surcharges) authorized based on the Number of DaysAuthorized, Rate, Policy Limits, and Direct Bill percent entered by theuser. This field will calculate the total amount to be authorized (basedon entry) when the USER clicks the Calculate screen function. RentalLocation Output 30 Rental Location Branch Name N/A Branch Name Output 30Rental Location Address Line N/A Address Output 30 Rental LocationAddress Line2 N/A Address Output 25 Rental Location City N/A City NameOutput 10 Rental Location Zip Code N/A Postal/Zip Code Output 3 RentalLocation State N/A State/Province Code Output 20 Rental LocationTelephone N/A Telephone Number Number Add the current Check 1 Add toFavorites NOT Should default to false location to my list box IndicatorSTORED (unchecked). of favorites If checked, the system should add thecurrent rental branch location to the favorites list in the user profileon the basis of the reservation. The branch location address will appearin the combo box on subsequent attempts until a description. FavoriteLocations Combo 30 Favorite Location location name The combo list shouldinclude Box the descriptions of each favorite location as identified inthe user profile. This field should default to ‘- Select a FavoriteLocation-’. If a favorite location is selected, the application willinstantly retrieve the favorite location and refresh the reservationscreen. Note to Enterprise Text 400 Authorization message text N/AMessage Note to Self Only Text 400 Diary Note diary note text The systemwill store the text entered into this field in the ARMS Web databasewith the authorization, but the message will not be sent to the branch.

-   -   2.3.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.3.3.1 More Locations            -   The More Locations screen function allows the USER to                select a different rental branch location using the Find                Rental Location use case. Invoking this screen function                will launch the USER into the Find a Rental Location use                case.            -   2.3.3.1.1 The More Locations screen function is invoked                through a button click.        -   2.3.3.2 Additional Charges            -   The Additional Charges screen function allows the USER                to add, view, and modify any additional charges that                they might authorize for a rental reservation (e.g.,                CDW). Invoking this screen function will launch the USER                into the Additional Charges use case.            -   2.3.3.2.1 The Additional Charges screen function is                invoked through a button click.        -   2.3.3.3 View Car Class            -   The View Car Class screen function allows the USER to                view and select a Rental Car Class to apply to a                reservation. Invoking this screen function will launch                the USER into the View Car Classes use case.            -   2.3.3.3.1 The View Car Class screen function is invoked                through a button click.        -   2.3.3.4 Select a Favorite Location            -   The Select a Favorite Location screen function allows                the USER to change the rental branch location to one of                the rental branch locations identified as a ‘favorites’                in their USER profile.            -   2.3.3.4.1 The Select a Favorite Location is invoked by                selecting a value from the Favorite Locations drop-down                list. The system should automatically retrieve the                favorite location (and rates) when the value of this                field is selected.        -   2.3.3.5 Confirm Reservation            -   The Confirm Reservation screen function allows the USER                to submit all reservation information to the ARMS Web                system, which will create a new reservation.            -   2.3.3.5.1 The Confirm Reservation screen function is                invoked either through a button click or by an Enter                keystroke.            -   2.3.3.5.2 If the information submitted to the ARMS Web                application is invalid or incomplete, this screen                function should prompt the USER with an error. The error                should be specific as to the cause of the failure. All                information previously entered should remain populated                in each field, with the problem field highlighted or                otherwise identified.        -   2.3.3.6 Cancel            -   The Cancel Reservation screen function will allow the                USER to leave the screen and return to their ARMS Web                start page. No information is saved and no reservation                is created.            -   2.3.3.6.1 The Cancel screen function is invoked through                a button click.

2.4 Reservation Confirmation Screen

-   -   The Reservation Confirmation screen provides the user interface        and functions to support Step 16 of the Basic Flow. This        provides the USER with confirmation feedback on successful        submission of the reservation.    -   2.4.1 Screen Layout—see FIGS. 106( a)-(c)    -   2.4.2 Screen Field Definition

Screen Field Screen Label Type Size Name Data Field Screen Specific RuleOffice Output 10 Office Location external organization abbreviated nameHandling for Output 35 Handling for First Name + Last Name Output 150Confirmation Authorized The screen should provide a Statement Days +statement that reads ‘You just Authorized authorized’ + AuthorizedDays + Rate + Renter ‘days at’ + Authorized Last Name + Rate/PolicyLimits + ‘/day for’ + Renter First Renter Last Name + ‘,’ + Name RenterFirst Name Don't show me Check 1 Delete confirmation If checked, thesystem should this confirmation box page not show this page again. pageagain Instead the system will provide the confirmation statement (above)in the feedback section of the page that the user is returned to (thearea of the EVERY page reserved for feedback, error messages, etc.)

-   -   2.4.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.4.3.1 Return to Home Page            -   The Return to Home Page screen function will allow the                USER to return to their home page from the reservation                confirmation screen.            -   2.4.3.1.1 The Return to Home Page screen function is                invoked through either a button click or an Enter                keystroke.        -   2.4.3.2 Change Reservation            -   The Change Reservation screen function will allow the                USER to go back into the Quick Reservation or Detailed                Reservation screen and change any errors.            -   2.4.3.2.1 The Change Reservation screen function is                invoked by clicking on the feedback hyperlink (e.g., You                just authorized 3 days at $29.39/day for Tom Hanks).

ARMS Web 3.0 Functional Design Specification Find a Rental LocationVersion 1.3 Find a Rental Location 1. Find a Rental Location Use Case1.1 Application Overview

-   -   The following is a document used to illustrate the process of        finding and selecting an alternate rental location for a        reservation created using ARMS/Web 3.0. The intent for this        release of the ARMS/Web application is to reach a much wider        audience. This application will target a Multi-Vendor,        Multi-Segment, and International customer base.

1.2 Brief Description

-   -   This use case describes the process of finding and selecting an        alternate rental location for a reservation created in the        ARMS/Web system. The USER will have the ability to select the        location search criteria they want to use (i.e. phone number or        postal code), select the rental company and select to either        review a list of nearby rental company locations or have the        system automatically determine a rental company location based        on the location search criteria. (The USER will also have the        ability to select an alternate location by using the ‘Favorite        Locations’ functionality built into the Create Reservation        screens.) This use case provides the mechanism to return rental        company location information, including address, rental company,        and phone number to create a new reservation or define a        favorite location.

1.3 Use Case Actors

-   -   The following actors will interact with this use case:        -   RENTAL ADMINISTRATOR—The RENTAL ADMINISTRATOR will use the            system to find and select a rental location for creating a            reservation. This use case refers to a USER in the role of a            rental administrator. There are various types of customers            that the rental administrator would represent, which include            corporate account holders, car dealerships, insurance            companies, and others.        -   LOCATOR—The LOCATOR system will determine the nearest rental            branch location(s) based on the search criteria provided in            this use case.        -   ARMS—The ARMS system will receive/send transactions to            ARMS/Web to retrieve the information regarding the rental            company.        -   RENTAL CAR COMPANY—A wide variety of rental car companies            will be able to use this system as well. Each company will            have the ability to initiate and manage their rentals            through the use of this application.

1.4 Pre-Conditions

-   -   The USER must be logged on to the ARMS/Web system.    -   The USER must be creating a reservation or defining a favorite        location.

1.5 Flow of Events

-   -   The Flow of Events includes all steps necessary to select rental        location search criteria and retrieve an alternate rental branch        location(s).    -   1.5.1 Activity Diagram—see FIG. 107.    -   1.5.2 Basic Flow        -   The Basic Flow of the Find a Rental Location use case            includes all of the required steps for the USER to select            and input search criteria to find an alternate rental            location. The USER will have the ability to view detailed            information about a rental branch, and select a rental            branch location to apply to a new reservation.            -   1. The USER selects to find an alternate rental                location.            -   2. The system will prompt the USER for pick up location                search criteria (also referred to as ‘where needed’                search criteria). This allows the USER to input a                telephone number, city, or postal code to find a rental                branch (or branches) that accepts ARMS/Web reservations                in a given area. (Rental branch locations have the                ability to opt out of accepting ARMS/Web reservations.)                The USER may also narrow the search by selecting a                particular rental company along with the location search                criteria. The USER will be given the option to view a                list of rental branch locations matching the search                criteria, or to have the ARMS/Web system automatically                select the rental branch considered the Nearest Match.            -   3. The USER enters the required search criteria.            -   4. The USER submits the rental branch location search                criteria.            -   5. The system will validate the rental branch location                search criteria.            -   6. The system will retrieve/return a rental branch                location (The requirements for retrieving a rental                branch location can be found on page 5 of this document                (Section 1.7.1 Requirements for Finding Rental                Location).) (based on USER search/selection criteria) to                be used by the Create Reservation use case. (This use                case is also used to define favorite locations from the                ‘My Profile’ use case. The location will be returned to                the ‘My Profile’ use case when the use case is entered                from a ‘My Profile’ screen.) The rental branch location                information for the selected branch on the Create                Reservation screens will be automatically populated with                the list below for the current Create Reservation                transaction.                -   Branch name (The Branch name has been included for                    future usability purposes (e.g., Network                    Allocation).)                -   Address                -   Telephone number                -   Rates            -   7. The use case is complete.    -   1.5.3 Alternative Flows        -   1.5.3.1 Search Criteria Entered is Invalid            -   If the USER enters an invalid Postal Code or Phone                Number as location search criteria, an error message                should be displayed to the USER and the USER should be                forced back into Step 2 of the Basic Flow. If the error                is specific to a data field, the field should be                highlighted and the error described.            -   1.5.3.1.1 It will be considered invalid if the ‘where                needed’ search criteria is a telephone number and the                first three digits (i.e., area code) meet the criteria                below:                -   0XX                -   1XX                -   the second and third digits equal (e.g., 800, 877,                    888, etc.)            -   Where X equals any digit 0 through 9.            -   1.5.3.1.2 It will be considered invalid if the ‘where                needed’ search criteria is a U.S. or Canadian telephone                number that does not consist of 10 digits.            -   1.5.3.1.3 It will be considered invalid if the ‘where                needed’ search criteria is a U.S. postal code that does                not consist of 5 or 9 digits.            -   1.5.3.1.4 It will be considered invalid if the ‘where                needed’ search criteria is a Canadian postal code that                does not consist of 6 alphanumeric characters in the                format AXAXAX where A is an alpha character and X is a                digit between 0 and 9.        -   1.5.3.2 No Rental Branch Locations Found            -   If the system cannot determine a rental branch location                based on the search criteria entered by the USER, Claims                Connection will be returned as the location and the use                case will end. Please refer to section 1.7.1                Requirements for Finding Rental Location on beginning on                page 5 of this functional specification for handling of                this situation.        -   1.5.3.3 View a List of Rental Branch Locations            -   If the USER opts to view a list of matching rental                locations, the list of matching locations will be                displayed after Step 5 of the Basic Flow. The USER will                have the ability to select one of these locations, view                more detail about the locations (i.e., maps, hours of                operation), or perform another location search by                entering new search criteria.            -   1.5.3.3.1 If the USER requests additional detail on a                specific rental branch in the View a List of Rental                Branch Locations Alternate Flow, the system should                display a screen with the selected branch's additional                information (Rental Company, Branch name, Addresses,                telephone/fax numbers, Map to the rental branch                location, Hours of operation). The USER should either                select the location from this screen (and be returned to                Step 6 of the Basic Flow), or be returned to the list of                matching locations by closing/continuing from this                screen.            -   1.5.3.3.2 If the USER wishes to perform another rental                branch location search in the View a List of Rental                Branch Locations Alternate Flow, the system should                return the USER to Step 2 of the Basic Flow.        -   1.5.3.4 Use Case Cancellation            -   The USER should be capable of leaving the use case at                any time.

1.6 Post-Conditions

-   -   If successful, a rental branch location will have been        determined and returned to the Create Reservation use case.    -   If unsuccessful, the system state remained unchanged.

1.7 Special Requirements

-   -   The additional requirements of the business use case are        included here. These are requirements not covered by the flow as        they have been described in the sections above.    -   1.7.1 Requirements for Finding Rental Location        -   Below are the requirements for finding a rental location in            the ARMS/Web system. ARMS/Web will resolve a rental location            and pass the location to ARMS for routing (which is a            deviation from current state handling). These requirements            were derived from the current state business requirements            for the ARMS locator system.        -   1.7.1.1 ARMS/Web will always return a rental branch location            for a reservation.            -   For all ARMS/Web reservations, the following rules for                finding a rental location apply:            -   1.7.1.1.1 For United States locations, the locator will                search a 50-mile radius around the renter's phone number                or postal code for the closest branch (or branches) that                accepts ARMS reservations. If the USER selects to review                a list of rental branch locations, an array of rental                branch locations meeting these criteria should be                returned.            -   1.7.1.1.2 For Canadian locations, the locator will                search a 50-mile radius around the renter's phone number                or postal code for the closest open branch (or branches)                that accepts ARMS reservations. If no open branches are                found, the closest branch (or branches) that accepts                ARMS reservations should be returned. If the USER                selects to review a list of rental branch locations, an                array of rental branch locations meeting these criteria                should be returned.        -   1.7.1.2 When the rental branch location is determined, the            system will retrieve the group/branch number, name, shipping            address, and telephone number of the rental branch location            and present them to the USER on the Create Reservation            screen(s).        -   1.7.1.3 The system will only display Claims            Connection (7680) as the location (with no rates) when no            location can be found within the 50-mile radius. If Claims            Connection is displayed, a message should be included to            indicate that no rental branch location was found within a            50-mile radius of the search criteria, and Claims Connection            will ensure that the reservation is handled appropriately.    -   1.7.2 Maintenance of Source Systems        -   This use case requires that several existing AS/400            databases be used to query for information:            -   Locator Database            -   Office Information Database        -   The use case requires that the information in these            databases be kept current and it is assumed that the group            responsible for maintaining these databases will continue to            do so in the future.

1.8 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Location Search Criteria Screen

-   -   This screen allows the USER to select/input the search criteria        they want to use to find a rental location. This screen supports        Steps 2 and 3 of the Basic Flow.    -   2.1.1 Screen Layout—see FIGS. 108( a) and (b)    -   2.1.2 Search for Rental Location

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleCountry Combo box 14 Country country code This list should consist ofUnited States and Canada. This will expand in future releases. Theselection will default to the home country of the USER as defined in theUSER profile. Input Text 20 Where Needed Value Where Needed Value RentalCombo box 20 Rental Company This is a list of all the Company rentalcompanies that are participating. Postal/Zip Radio 1 Postal/Zip Code NOTSTORED Code Button Button Telephone Radio 1 Telephone Button NOT STOREDThis should be the Button default radio button selection. City Radio 1City Radio Button NOT STORED Button Automatically Checkbox 1 Nearestmatch This checkbox select the Selection should default to nearestoffice checked.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Next            -   The Next screen function will allow the USER to submit                the information on the Location Search Criteria screen                and initiate the search for matching locations.            -   2.1.3.1.1 The Next screen function is launched through                either a button click or by using the Enter keystroke.            -   2.1.3.1.2 If the information submitted to the ARMS/Web                system is invalid or incomplete, this screen function                should prompt the USER with an error. The error should                be specific as to the cause of the failure. All                information previously entered should remain populated                in each field, with the problem field highlighted or                otherwise identified.

2.2 Matching Location Screen

-   -   This screen allows the USER to review/select a rental location        based on the search criteria entered on the Location Search        Criteria screen. The screen will present 5 matching records at a        time to the USER. The USER is given the option of viewing        additional detail on a location or entering new search criteria.        If there are more locations selected by the search, the USER        will view the next locations (up to 5). This screen supports        Step 4 of the Basic Flow.    -   2.2.1 Screen Layout—see FIGS. 109( a) and (b)    -   2.2.2 Screen Field Definition

Screen Label Type Length Screen Field Name Data Field Screen SpecificRule Radio 1 Selector Radio A radio button should be Button Buttonpresented for every rental branch location record in the list. Only oneradio button may be selected. The rental branch location that is theshortest distance from the search criteria entered should be thedefault. Location Output 30 Rental Location Address Line A locationshould be Address presented for every rental branch location record inthe list. Rental Output 30 Rental Company The name of the rental Companyname company that is available from the search criteria. Miles Output 4Miles from Search Miles from search criteria Criteria should bepresented for every rental branch location record in the list. CityOutput 18 Rental Location City City A city should be presented Name forevery rental branch location record in the list. State/Province Output 2Rental Location State A state/province should be State/Province Codepresented for every rental branch location record in the list. CountryDrop 14 Country NOT This list should consist of Down STORED UnitedStates and Canada. This will expand in future releases. The selectionwill default to the home country of the USER as defined in the USERprofile. Input Text 12 Where Needed Value Where Needed Value RentalCombo 20 Rental Company This is a list of all the rental Company boxcompanies that are participating. Postal/Zip Radio 1 Postal/Zip Code NOTCode Button Button STORED Telephone Radio 1 Telephone Button NOT Thisshould be the default Button STORED radio button selection. City Radio 1City Radio Button NOT Button STORED Automatically Checkbox 1 NearestMatch NOT This should default to select the Selection STORED checked.nearest office

-   -   2.2.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.2.3.1 Select this Location            -   The Select this Location screen function will submit the                selected rental branch location in the Rental Location                Information Container to the ARMS/Web system, to be used                by the Create Reservation use case.            -   2.2.3.1.1 The Select this Location screen function is                launched through either a button click or by using the                Enter keystroke.        -   2.2.3.2 Next X of Y            -   The Next X of Y screen function will allow the USER to                view the next five rental locations (unless less than                five records exist) that match the search criteria. For                example, if a total of 8 locations were returned as part                of the search, this screen function would be presented                as Next 3 of 8.            -   2.2.3.2.1 The Next X of Y screen function is launched                through a button click.            -   2.2.3.2.2 The Next X of Y screen function should not be                presented if 5 or fewer records are retrieved.            -   2.2.3.2.3 The Next X of Y screen function should have                the X values replaced by the number of records remaining                to view (up to five) in this search.            -   2.2.3.2.4 The Next X of Y screen function should have                the Y value replaced by the number of total records                returned in the search.        -   2.2.3.3 Previous 5 of Y            -   The Previous 5 of Y screen function will allow the USER                to view the previous five rental locations that matched                the search criteria (and were previously reviewed).            -   2.2.3.3.1 The Previous 5 of Y screen function is                launched through a button click.            -   2.2.3.3.2 The Previous 5 of Y screen function should not                be presented on the initial search results screen. The                Previous 5 of Y screen function should only be available                if the USER has selected the Next X of Y screen                function.            -   2.2.3.3.3 The Previous 5 of Y screen function should                have the Y value replaced by the number of total records                returned in the search.        -   2.2.3.4 Details/Map            -   The Details/Map screen function allows the USER to                review additional information about a rental location                presented in the list of matching records. Selecting                this screen function will open the Location Details                screen for the rental branch selected.            -   2.2.3.4.1 The Details/Map screen function is launched                through a button click.            -   2.2.3.4.2 Each rental branch location presented in the                list of matching locations should have its own                Details/Map button.        -   2.2.3.5 Search Again            -   The Search Again screen function will allow the USER to                submit the Location Search Criteria Container                information on the Matching Location screen and                re-initiate the search for matching locations.            -   2.2.3.5.1 The Search Again screen function is launched                through a button click.            -   2.2.3.5.2 If the information submitted to the ARMS/Web                system is invalid or incomplete, this screen function                should prompt the USER with an error. The error should                be specific as to the cause of the failure. All                information previously entered should remain populated                in each field, with the problem field highlighted or                otherwise identified.

2.3 Location Details Screen

-   -   This screen allows the USER to view additional details for a        given rental location. This screen supports the View Location        Detail alternate flow.    -   2.3.1 Screen Layout—see FIGS. 110( a) and (b)    -   2.3.2 Screen Field Definition

Screen Label Type Length Screen Field Name Data Field Screen SpecificRule Output Rental Location Rental Name Location Output Rental CompaniesName Output Rental Location Address Line Address Output Rental LocationCity State + City + Rental Location City Name + Name + “,” + Rental ZipCode “,” + Rental Location Location State/Province Code + “” + RentalLocation Postal/Zip Code Output Rental Location Telephone Text TelephoneNumber Number Mon Output Rental Location Start Rental Location StartHours Text Hours of Operation + of Operation + “-” + Rental “-” + RLocation End Hours of Operation This should be filled with the start andend hours of operation for the ‘Monday’ value in the hours of operationarray. Tue Output Rental Location Start Rental Location Start Hours TextHours of Operation + of Operation + “-” + Rental “-” + R Location EndHours of Operation This should be filled with the start and end hours ofoperation for the ‘Tuesday’ value in the hours of operation array. WedOutput Rental Location Start Rental Location Start Hours Text Hours ofOperation + of Operation + “-” + Rental “-” + R Location End Hours ofOperation This should be filled with the start and end hours ofoperation for the ‘Wednesday’ value in the hours of operation array. ThuOutput Rental Location Start Rental Location Start Hours Text Hours ofOperation + of Operation + “-” + Rental “-” + R Location End Hours ofOperation This should be filled with the start and end hours ofoperation for the ‘Thursday’ value in the hours of operation array. FriOutput Rental Location Start Rental Location Start Hours Text Hours ofOperation + of Operation + “-” + Rental “-” + R Location End Hours ofOperation This should be filled with the start and end hours ofoperation for the ‘Friday’ value in the hours of operation array. SatOutput Rental Location Start Rental Location Start Hours Text Hours ofOperation + of Operation + “-” + Rental “-” + R Location End Hours ofOperation This should be filled with the start and end hours ofoperation for the ‘Saturday’ value in the hours of operation array.

-   -   2.3.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.3.3.1 Select this Location            -   The Select This Location screen function will submit the                selected rental branch location to the ARMS/Web system,                to be used in other parts of the system.            -   2.3.3.1.1 Clicking on the Select This Location hyperlink                launches the Select This Location screen function.        -   2.3.3.2 Previous            -   The Previous screen function will return the USER to the                list of locations that was presented based on the search                criteria that were entered.            -   2.3.3.2.1 Clicking on the Prey button launches the                Previous screen function.        -   2.3.3.3 Enlarge Map            -   The Enlarge Map Screen function will retrieve a larger                graphic image of the map to the location. The larger                image will be placed in the same screen location of the                Location Details screen.            -   2.3.3.3.1 Clicking on the Enlarge Map hyperlink launches                the Enlarge Map screen function.        -   2.3.3.4 Reduce Map            -   The Reduce Map Screen function will retrieve a smaller                graphic image of the map to the location. The smaller                image will be placed in the same screen location of the                Location Details screen.            -   2.3.3.4.1 Clicking on the Reduce Map hyperlink launches                the Reduce Map screen function.        -   2.3.3.5 Zoom In            -   The Zoom In screen function will retrieve a more                specific (more detailed) graphic image of the map to the                location. The more specific image will be placed in the                same screen location of the Location Details screen.            -   2.3.3.5.1 Clicking on the Zoom In hyperlink launches the                Zoom In screen function.        -   2.3.3.6 Zoom Out            -   The Zoom Out screen function will retrieve a more                general (less specific) graphic image of the map to the                location. The more general image will be placed in the                same screen location of the Location Details screen.            -   2.3.3.6.1 Clicking on the Zoom Out hyperlink launches                the Zoom Out screen function.

3. Questions and Answers

-   -   Issue Number: 307    -   Question: We have heard from the business that the search by        name criteria needs to be better. Today we search by the first        three letters of the last name. We need to know what criteria is        the preferred method of search to be done.    -   For example: Do we search the entire last name and first name?        -   Do we search by the first three letters of the last name and            the first letter for the first name?        -   Do we search by first letter of last name and first letter            of first name? Need the Business Rule.    -   Status: 12 User Review    -   Resolution: 4-17-00, Sean O'Donnell—We have spoken to the Rental        Redesign folks to find out how they are doing last/first name        matching, and they are not planning to search by name in the new        rental system (Telephone Number, Driver's License, and SSN        only). They were going to have an ‘implied wildcard’ search by        name, but it was taken out in USER review.    -   Issue Number: 310    -   Question: Do we want the ARMS/Web to have search available by        phone, zip code/postal code, city and state. Current state only        allows for phone number searches. Do we want to search other        than phone number    -   For example: Do we want to search by phone number or zip code?        -   Do we want to search by phone number or zip code or city?    -   Need Business Rule    -   Status: Closed—Resolved    -   Resolution: 3-16-00, Jen Cavanaugh—Talking with Dave Smith.        3-22-00, Issue Mtg. Search by phone # & zip code only.        -   (SHOULD THE ANSWER BE “SEARCH BY PHONE # AND/OR ZIP CODE?)            yes it is and/or could be both or one.    -   Issue Number: 311    -   Question: If a daily rental branch is closed, how do we want the        system to work?Current state it defaults to Claims Connection.        We need clarification on how this should work in the ARMS/Web        environment.    -   3-17-00, Application Team—What do we want to see in the locator,        do we want to see just open only or all? If no branch is open do        we return to Claims Connection?    -   Status: Closed—Resolved    -   Resolution: 3-16-00, Jen Cavanaugh—Stan's team is going to get        w/claims Connection to see how this process works after hours.        From there we will make some business decisions 3-20-00,        Jennifer Cavanaugh—Stan's team needs to research how ARMS &        Retail Res Locator works & how they differ. Then we will        re-review the question.    -   3-27-00, Sean—I talked with Trent Tinsley and Kim Devallance on        this topic, which was EXTREMELY helpful. If the adjuster selects        a closed branch, the system will route the ticket based on the        type of service established in the insurance company profile:    -   Insurance companies that do NOT have 24-hour service, the        reservation will be routed to the branch that was selected. The        branch will do a callback in the morning when they re-open.        Insurance companies that have 24-hour service have their        reservations re-routed to Claims Connection (who will do a        callback prior to 9 pm in any time zone unless otherwise        specified by an adjuster) if the selected office is not open.        This determination is made in the background after the adjuster        submits the reservation. Claims connection will re-route the        reservation to the appropriate branch when the customer is        contacted. Essentially, the way that location selection is        handled today can/should be supported in the future version of        ARMS/Web (location selection is implied through the F2-Rates        function of ARMS/400). Please let me know if you have questions        with regard to this issue update/resolution.    -   Issue Number: 374    -   Question: In the Create Reservation functional specification, we        have stated that the system will pull a location and rates        immediately for the USER. The issue arises when we have no        location to retrieve, in cases that the ‘where needed’ search        criteria is weak or we don't have a branch within 50 miles of        the search area. In the current state, we show Claims Connection        as if it were a branch in this situation. This can be somewhat        confusing (to see the location of Hanley Road in St. Louis if        you are in Delaware). In the future state, we think it may be a        good idea to notify the USER that no location was found, and        that the reservation would be handled by Claims Connection (see        example message below). Any thoughts on this question . . . .

Example Message:

-   -   A rental branch could not be found within 50 miles of        555-512-5000. Claims Connection will ensure your reservation is        handled immediately. Please call 800-CLAIMSCONNECTION for        additional assistance.    -   Status: Pending    -   Resolution: 5-8-00, Response from Sean O'Donnell: Dave liked the        idea, and so did Kim. Have not heard from Randy on this one,        though. Let me know if you need me to follow up, otherwise this        will be written in to the specification for Finding a rental        location.

ARMS Web 3.0 Functional Design Specification Send Message Version 1.1Send Message 1. Send Message Use Case 1.1 Brief Description

-   -   This use case describes the process of capturing messages and        diary notes associated with a rental reservation/authorization.        The USER can elect to either have the message sent to the        Enterprise rental branch location responsible for the        reservation/authorization (MESSAGE in this document), or to        store the note in the ARMS Web system without sending the        message to Enterprise (DIARY NOTE in this document). All        MESSAGES and DIARY NOTES captured must be related to a specific        reservation/authorization.    -   NOTE: This is a sub-use case that must be accessed from another        use case. For example, a USER may send a message while creating        a reservation, maintaining an authorization, or completing an        extension.

1.2 Use Case Actors

-   -   The following actors will interact with this use case. All        actors are referred to as USER throughout this use case:        -   ADJUSTER—The ADJUSTER will use this use case to enter and            send a message about a reservation/authorization to the            rental branch location that is responsible for the            reservation/authorization. The ADJUSTER may also use this            use case to capture diary notes.    -   PROCESSOR—The PROCESSOR will use this use case to enter and send        a message about a reservation/authorization to either the rental        branch location or the ADJUSTER that is responsible for the        reservation/authorization.    -   ENTERPRISE ADMINISTRATOR—The ENTERPRISE ADMINISTRATOR will use        this use case to send a message on a specific transaction to        notify the rental branch location or other user of        issues/complications in transmission of the transaction.

1.3 Pre-Conditions

-   -   The USER must be signed-on to the ARMS Web system.    -   The USER must have selected an authorization that is in a state        that allows MESSAGES or DIARY NOTES.

1.4 Flow of Events

-   -   The Flow of Events includes all steps necessary to enter        MESSAGES and DIARY NOTES.    -   1.4.1 Activity Diagram—see FIG. 111.    -   1.4.2 Basic Flow        -   The Basic Flow of the Send Message use case includes all of            the required steps for the USER to enter a MESSAGE or DIARY            NOTE.        -   1. The USER will indicate that they want to send a MESSAGE            for a reservation/authorization.        -   2. The system will display a screen that will capture the            message/note text.        -   3. The USER will enter the message/note text.        -   4. The USER returns to the parent use case, and the system            stores the text message to be sent at a later time (see            Special Requirements).        -   5. This ends this use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Send Diary Note Only            -   The USER will have the ability to indicate that the                MESSAGE text should be stored as a DIARY NOTE only in                Step 3 of the Basic Flow. This text should not be sent                to the Enterprise rental branch location handling the                reservation/ticket.        -   1.4.3.2 Use Case Cancellation            -   The USER should be capable of leaving the use case at                any time.

1.5 Post-Conditions

-   -   If successful, the message/note text will be updated in the ARMS        Web database. MESSAGES requested to be sent to the rental branch        location are sent to ARMS.    -   If unsuccessful, the system state remains unchanged.

1.6 Special Requirements

-   -   1.6.1 Submit Message Responsibilities        -   The parent use case that accessed this function will have            the responsibility of submitting the text message to the            ARMS Web database. Based on USER input, the parent use case            must complete the following action:            -   If the USER chose to have the text sent to the rental                branch location as a MESSAGE, the text will be written                to the ARMS Web database and the MESSAGE will be sent to                ARMS. ARMS will forward the text to ECARS for                distribution to the appropriate rental branch.            -   If the USER chose to save the text as a DIARY NOTE, the                text will be written to the ARMS Web database as a DIARY                NOTE only.

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   As noted in the Send Message Use Case, the Send Message function        will be available on multiple screens throughout the system        (e.g., Create Reservation, Extend Rental, Change Authorization).        This section provides functional description of the screen        container that is used on the multiple screens to support the        Send Message use case.

2.1 Message Screen Container

-   -   2.1.1 Screen Layout—see FIG. 112. (This is the screen layout for        the Create Reservation screen. The Message screen container is        part of this screen, and is shown here for illustrative purposes        only.)    -   The area of the screen under consideration is the container        beginning with the Notebook heading. This is an example of how        the message container might look on any given screen.    -   2.1.2 Message Screen Container

Screen Label Type Length Screen Field Name Data Field Screen SpecificRule Note to Input Text 200 Message Text message text Text entered intothis field Enterprise will be sent to the Enterprise rental branchlocation. Note to Self Input Text 200 Message Text Diary text Textentered into this field Only will be stored in the ARMS Web database butwill not be sent to the Enterprise rental branch location.

-   -   2.1.3 Screen Function Definition        -   The Message screen container will use the functions of the            parent screen to have the message sent.

3. Questions and Answers

-   -   Issue Number: 341    -   Question: Current state ARMS400 allows user to enter maximum of        four lines of fifty characters. Current state ARMS has program        limitation of ten lines of fifty characters. ARMS Web will be        limited by current state ARMS. Should that be the planned        maximum for ARMS Web or??? One idea would be to have the number        of lines/characters profiled. Then the size of the message box        that is displayed to the user would be limited by this profiled        amount.    -   Status: Closed—Resolved    -   Resolution: 3-30-00, Kim De Valiance—I think ten lines of fifty        characters to be entered by any user at a time is more than        enough. I don't really for see the need to profile this by        company.    -   Issue Number: 342    -   Question: Current state allows message to be sent on        unauthorized requests only if they have not been assigned to an        adjuster. How should future state work? If we allow messages on        assigned unauthorized requests, we must keep in mind that we are        defaulting the Direct-Bill To percent at 100% on all auth.        screens. When the adjuster submits the message, they MAY be        unintentionally authorizing the request.    -   Status: Closed—Resolved    -   Resolution: 3-30-00, Kim De Valiance—Kim: we should never send        an authorization to the branch if all the adjuster did was key        in a message. The message will either appear in ECARS under res        notes or callback notes, but should never appear to the branch        as an authorization. We not only need to give the adjuster the        ability to send a message, but they should be able to change        info (such as claim number, claim type, etc.) before assigning        the request to the adjuster, thereby enabling the adjuster to        see the correct info when authorizing or denying a DB. We hear        this request a lot from our customers.

Functional Design Specification Additional Charges Version 1.2Additional Charges 1. Additional Charges Use Case 1.1 Brief Description

-   -   The Additional Charges use case will allow the USER to view,        add, or modify/remove any additional charges that may be        associated with a rental authorization. Additional Charges such        as Collision/Damage Waiver (CDW), Mileage Charge, or any other        rental related charge could be authorized by a USER through this        function.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:    -   ADJUSTER—The ADJUSTER will use this use case to view, add, or        modify any additional charges that are associated with a rental        authorization.

1.3 Pre-Conditions

-   -   The USER must be signed-on to the ARMS Web system.    -   The USER must have a reservation or open ticket selected        (active).

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps to view, add        and modify additional charges associated with a rental        authorization.    -   1.4.1 Activity Diagram—see FIG. 113.    -   1.4.2 Basic Flow        -   The Basic Flow of the Additional Charges use case includes            all of the required steps to view, add, or modify Additional            Charges as part of an authorization.        -   1. The USER will select Additional Charges for the active            reservation or open ticket.        -   2. The system will prompt the USER to add, modify or remove            Additional Charges.        -   3. The USER will view, add, or modify Additional Charges            that will be authorized.        -   4. The USER will submit the Additional Charges to the            system.        -   5. The system will validate the Additional Charges entered            by the USER.        -   6. The system will return the USER to the active reservation            or open ticket and populate Additional Charges. (The            Additional Charges should not be submitted to the ARMS Web            database until the USER submits the changes on the active            reservation or open ticket.)        -   7. This ends this use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Additional Charges Invalid            -   If the Additional Charges entered by the USER are                invalid, the system should present an error message to                the USER and force the USER back into Step 2 of the                Basic Flow. The system will declare additional charges                invalid in the following circumstances:            -   1.4.3.1.1 It will be considered invalid if the                additional charge type is ‘Dollars per Day’ or ‘Dollars                per Rental’ and the additional charge value entered is                greater than $999.99.            -   1.4.3.1.2 It will be considered invalid if the                additional charge type is ‘Dollars per Day’ or ‘Dollars                per Rental’ and the additional charge value entered is                less than $0.            -   1.4.3.1.3 It will be considered invalid if the                additional charge type is ‘Percentage of Rental’ and the                additional charge value entered is greater than 100%.            -   1.4.3.1.4 It will be considered invalid if the                additional charge type is ‘Percentage of Rental’ and the                additional charge value entered is less than 0%.

1.5 Post-Conditions

-   -   If successful, the Additional Charges that were added or        modified will be returned to the active reservation or open        ticket.    -   If unsuccessful, no Additional Charge will be added to the        active reservation or open ticket.

1.6 Special Requirements

-   -   The additional requirements of the business use case are        included here. These are requirements not covered by the flow as        they have been described in the sections above.    -   1.6.1 Submit Additional Charges Responsibilities        -   The parent use case that accessed this function will have            the responsibility of submitting the additional charges to            the ARMS Web database. Any additional charges returned to a            parent use case should be reflected on the screen within            that use case. For example, if additional charges were being            added as part of the Create Reservation process, the Create            Reservation screens should have some indication that            additional charges have been added.    -   1.6.2 Additional Charges Descriptions        -   Below are the current additional charge descriptions used in            the ARMS/400 system in the current state:

DAMAGE WAIVER SPECIAL PAI DROP CHARGE MILEAGE CHARGE MISC CHARGES HOURLYSLP DAILY UNDERAGE DRIVER WEEKLY BABY CAR SEAT MONTHLY SKI RACK

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Additional Charges

-   -   This screen will allow the user to view, add, modify or remove        additional charges associated with a reservation/authorization.    -   2.1.1 Screen Layout—see FIG. 114.    -   2.1.2 Screen Field Definition

Screen Label Type Length Screen Field Name Data Field Screen SpecificRule CDW (Collision Check 1 CDW (Collision Damage Box Damage Waiver)Waiver) PAI (Personal Check 1 PAI (Personal Accident Box AccidentInsurance) Insurance) Underage Check 1 Underage Driver Driver Box DropCharge Check 1 Drop Charge Box Mileage Check 1 Mileage Charge Charge BoxMisc. Charge Check 1 Misc. Charge Box Check Box Create Charge Text Box15 Additional Charge A description of the Type Description additionalsurcharge to be authorized. Amount Text Box 6 Additional Charge AnAmount text box should Value be included for every check box on thescreen. Type Combo 20 Additional Charge A Type combo box should Box Typebe included for every check box on the screen. Values include: Dollarsper Day (DEFAULT); Dollars per Rental; Percentage of Rental

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Create More Surcharges            -   The Create More Surcharges screen function will allow                the USER to select the hyperlink and have an additional                Misc. Charge line added to the screen. For example, the                Screen Layout above shows only one Misc. Charge box. If                a USER were to click on the Create More Surcharges                hyperlink, the screen would refresh and provide the user                with two Misc. Charges boxes. The USER is not limited to                the number of Misc. Charge boxes that can be added.            -   2.1.3.1.1 The Create More Surcharges screen function is                invoked through clicking a hyperlink.        -   2.1.3.2 Process            -   The Process screen function allows the USER to save the                additional charges that are being authorized and return                to the active reservation or open ticket. The active                reservation or open ticket will reflect that additional                charges have been added.            -   2.1.3.2.1 The Process screen function is invoked through                a button click or through an Enter keystroke.        -   2.1.3.3 Previous            -   The Previous screen function will allow the USER to                return to the active reservation or open ticket without                saving the updates to additional charges.            -   2.1.3.3.1 The Previous screen function is invoked                through a button click.

3. Questions and Answers

-   -   None.

Functional Design Specification View Car Class Version 1.2 View CarClass 1. View Car Class Use Case 1.1 Brief Description

-   -   This use case will allow the USER to view examples of        automobiles that are part of each Enterprise Car Class. The USER        will have the ability to select a car class and have the rate        for the car class apply to the reservation/authorization.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:        -   ADJUSTER—The ADJUSTER will use the case to view and/or            select the car class that will apply to a reservation.

1.3 Pre-Conditions

-   -   The USER must be signed-on to the ARMS Web system.    -   The USER must have a reservation or open ticket selected.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps to view        and/or select the car class to apply to a rental reservation.    -   1.4.1 Activity Diagram—see FIG. 98.    -   1.4.2 Basic Flow        -   The Basic Flow of the View Car Class use case includes all            of the required steps to view and/or select a car for a            rental reservation. If a car class is selected, it will be            used to populate rate information on a rental authorization.        -   1. The USER will select View Car Class from the active            reservation or open ticket.        -   2. The system will display a car class detail screen. If the            USER had previously selected a car class (for example, on            the Create Reservation screen), the car class selected will            be displayed. If no car has been selected, the system will            display the Standard car class.        -   3. The USER will select the car class to apply to the            reservation or open ticket.        -   4. The system will return the USER to the active reservation            or open ticket and populate car class information based on            the car class selected.        -   5. This ends this use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Select Alternate Car Class        -   From Step 2 of the Basic Flow, the USER will have the            ability to view an alternate car class. The car classes that            will be available to view include:            -   Economy            -   Compact            -   Intermediate            -   Standard            -   Full Size            -   Premium        -   If the USER selects an alternate car class, the system will            refresh and present the details of the new car class.        -   1.4.3.2 Populate Car Class Rates            -   If a rental branch location has already been selected                prior to entering this use case, the selection of a car                class will populate the rates that apply to the selected                car class on the active reservation or open ticket. This                alternate flow returns the USER to Step 4 of the Basic                Flow.

1.5 Post-Conditions

-   -   If successful, the selected Car Class will be returned to the        active reservation or open ticket.    -   If unsuccessful, the system state is unchanged.

1.6 Special Requirements

-   -   The additional requirements of the business use case are        included here. These are requirements not covered by the flow as        they have been described in the sections above.    -   1.6.1 Modify Car Class Selection Results    -   The USER may change the results of this use case as part of the        active reservation or open ticket.

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Car Class Detail Screen

-   -   This screen (see FIG. 99( a)) will allow the USER to view        detailed information about Enterprise car classes. The USER will        also have the ability to select a car class to apply to a rental        reservation/authorization.    -   2.1.1 Screen Layout—see FIG. 99( a)    -   2.1.2 Car Class Details

Screen Label Type Length Screen Field Name Data Field Screen SpecificRule Output 20 Car Class Name This should be the name of the currentlyselected car class. (Person Output 2 Car Class Person This shouldprovide the Image) Capacity average person capacity of the selected carclass. (Luggage Output 2 Car Class Luggage This should provide theImage) Capacity average luggage capacity of the selected car class.Hidden 255 Car Class Image This should provide a Source picture of anexample car within the selected car class. Output 120 Car Class DetailThis should provide a Description description of the selected car class.Economy Output Economy Car Class This should be a hyperlink to theEconomy car class detail. Compact Output Compact Car Class This shouldbe a hyperlink to the Compact car class detail. Intermediate OutputIntermediate Car This should be a Class hyperlink to the Intermediatecar class detail. Standard Output Standard Car Class This should be ahyperlink to the Standard car class detail. Full Size Output Full SizeCar Class This should be a hyperlink to the Full Size car class detail.Premium Output Premium Car Class This should be a hyperlink to thePremium car class detail.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Select This Car Class            -   The Continue screen function will allow the USER to                select the car class to apply to a reservation.            -   2.1.3.1.1 The Continue screen function is invoked                through either a button click or through an Enter                keystroke.        -   2.1.3.2 Previous            -   The Previous screen function allows the USER to return                to the previous screen.            -   2.1.3.2.1 The Previous screen function is invoked                through a button click.

3. Questions and Answers

-   -   None.

Functional Design Specification Assign a Request Version 1.1 Assign aRequest 1. Assign a Request Use Case 1.1 Brief Description

-   -   This use case describes the process of how a USER will review        unassigned authorization request and assign them to an adjuster        for further handling.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:    -   CLAIMS PROCESSOR—The CLAIMS PROCESSOR is a USER who can perform        this use case to assign a request for further handling.    -   ADJUSTER—The ADJUSTER is a USER who can receive the assigned        request for further handling.

1.3 Pre-Conditions

-   -   The USER must be signed-on to the ARMS Web system.    -   The USER should be authorized to assign a request.    -   If there are unassigned requests present, the USER has selected        the link from the Review List Action Items Use Case to enter        this use case.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps to make        changes and updates to “Assign an Action Item”.    -   1.4.1 Activity Diagram—see FIG. 115.    -   1.4.2 Basic Flow        -   1. The USER selects the unassigned authorizations link.        -   2. The system retrieves all unassigned request summaries.        -   3. The system retrieves all OFFICE IDs within ARMS Web.        -   4. The system retrieves all USER IDs within the OFFICE.        -   5. The system displays the unassigned authorization            summaries with the offices and adjusters.        -   6. The USER selects an adjuster to assign to the request.        -   7. The system will update the ARMS Web database.        -   8. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Cancel Use Case            -   The USER should be capable of leaving the use case at                any point prior to assigning the reservation information                to an ADJUSTER.        -   1.4.3.2 Modify a Request            -   Before step 6 of the basic flow, the USER should be able                to make changes to the authorization.        -   1.4.3.3 Select a different office            -   Before step 6 of the basic flow, the USER should be able                to select a different office for this authorization                request. If a different office has been selected, the                user cannot assign the file to a new adjuster. The new                office must now assign the file.

1.5 Post-Conditions

-   -   If the use case is successful, the system will change the        request type from an unassigned authorization request to direct        bill. If the user has authority to authorize this request, the        system will change the request to Authorized status and assign        the adjuster picked in Step 5 of the basic flow.    -   If the use case is unsuccessful, the system state will remain        unchanged.

1.6 Special Requirements

-   -   None.

1.7 Extension Points

-   -   1.7.1 MA-04 Send Message        -   The Send Message function will be used to allow the user to            capture messages and diary notes associated with a rental            reservation/authorization. The USER can elect to have the            message sent to the Enterprise rental branch location            responsible for the reservation/authorization. The USER may            also send a message without assigning the file to an            adjuster/office. All MESSAGES and DIARY NOTES captured must            be related to a specific reservation/authorization.    -   1.7.2 MA-10 Authorize a Request        -   The ADJUSTER may decide to enter into the full detail screen            of the unassigned request, which would invoke the Authorize            a Request case.    -   1.7.3 MA-17 Cancel Authorization        -   At any point prior to assigning the file to an ADJUSTER, the            USER should have the ability to cancel the authorization. If            the authorization is canceled, the ADJUSTER will be prompted            to select a cancellation reason code from a drop down list            along with having the option to enter additional comments.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Action Items—Unassigned

-   -   This screen will allow the USER to assign action items to a        claims office or an adjuster or the USER may cancel an item. The        USER may also change specified information in the Customer File        through this screen.    -   2.1.1 Screen Layout—Action Items—Unassigned—see FIG. 116.    -   2.1.2 Action Items—Unassigned

Screen Specific Screen Label Type Size Screen Field Name Data Field NameRule Claims Office Output 3 Office Id external organization N/A.abbreviated name Handling For: Output 30 Handling for First Name + LastN/A. Adjuster's Name Name Output 30 Renter's Name First Name + Last Thisshould be a link. Name The USER should be able to get to the authorizepage from this screen field. Output 30 Renter's Address Address LineOutput 10 Renter's City City Output 3 Renter's State State Output 10Renter's Zip Code Zip Code Output 16 Renter's Home Renters Night Phone +If these fields are Phone Renters Night populated, add a Phone Extensionlabel to the screen to differentiate between Home Phone and Work Phone.Output 16 Renter's Work Phone Day Phone + If these fields are RentersDay Phone populated, add a Extension label to the screen todifferentiate between Home Phone and Work Phone. Claim Number Input 30Claim Number Insurance Claim N/A. Number Vehicle List Box 15 Loss Typeloss type description Condition Claim Type List Box 15 Claim Type claimtype N/A. description Date of Loss: Input 10 Date of Loss Date of LossN/A. Note to Input 30 Message Text NOTE N/A. Enterprise Assign to ListBox 5 Office Id external organization office: abbreviated name AssignList Box 30 Adjuster Name First Name + Last Lists only those adjuster:Name adjusters the USER has authority to assign.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1<<Previous            -   When clicked, the USER will be taken back to the                previous screen.        -   2.1.3.2 Process            -   When clicked, the USER will be taken to the next item in                the action item list or a detail of the completed action                items. This button ends the use case.        -   2.1.3.3 Cancel            -   When clicked, the USER will be allowed to cancel the                authorization. If this occurs, the rental becomes                unauthorized and the rental is no longer the                responsibility of the insurance company.        -   2.1.3.4 Last Action Message            -   After each action item in the USER's list has been                completed, upon arriving at the next item there will be                a confirmation message at the top of the screen. This                message will be a hyperlink describing the last                completed action. If the USER clicks on this link, the                system will open the customer file, which will reflect                all of the current information for the rental. The USER                is then free to make additional changes or to simply                view the file.

3. Application Operations 4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 Address Line

Entity ARM: Renter Detail Column Name RKADL1 Label Name Address LineSystem Name Data Type CHAR(30) Attribute Definition

-   -   4.1.2 City

Entity ARM: Renter Detail Column Name RKCYNM Label Name City System NameData Type CHAR(20) Attribute Definition

-   -   4.1.3 claim type code

Entity AUTHORIZATION EXTENSION Column Name Clm_typ_cde Label Name claimtype code: System Name CLMTYPCDE Data Type DEC(3,0) Attribute DefinitionThe claim type code defines the different Authorization claim types. Forexample: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.4 claim type description

Entity CLAIM TYPE Column Name clm_typ_dsc Label Name claim typedescription: System Name CLMTYPDSC Data Type CHAR(40) AttributeDefinition The claim type description is a lexical definition of theclaim type code which defines the different Authorization claim types.For example: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.5 company identifier

Entity EXTERNAL ORGANIZATION Column Name cmpy_id Label Name companyidentifier: System Name CMPYID Data Type DEC(11,0) Attribute DefinitionBusiness Party Identifier is a surrogate key assigned to each uniqueoccurrence of an Individual, External Organization, and InternalOrganization (Business Party).

-   -   4.1.6 DATE OF LOSS

Entity A4 Cross Reference Column Name X4LSDT Label Name DATE OF LOSSSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.7 Day Phone

Entity ARM: Renter Detail Column Name RKDYPH Label Name Day Phone SystemName Data Type NUMERIC(10) Attribute Definition

-   -   4.1.8 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute Definition External Organization Abbreviated Name isa shortened text based label associated with an organization outside ofEnterprise. This name is sometimes used for accounting purposes.

-   -   4.1.9 external organization identifier

Entity EXTERNAL ORGANIZATION Column Name e_o_id Label Name externalorganization identifier: System Name EOID Data Type DEC(11,0) AttributeDefinition The external organization identifier is a surrogate keyassigned to each unique occurrence of an External Organization.Examples: body shops, vehicle manufacturers, insurance companies,leasing accounts, credit unions, dealerships, or government agencies.

-   -   4.1.10 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.11 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.12 handled by adjustor code

Entity ACTION ITEM Column Name handl_by_adjr_cde Label Name AdjustorCode System Name HNDADJRCDE Data Type CHAR(10) Attribute Definition Thehandled by adjustor code is the adjustor code of the administrator oradjustor's who is handling the action item.

-   -   4.1.13 handled by company identifier

Entity ACTION ITEM Column Name handl_by_cmpy_id Label Name ARMS ProfileID System Name HNDCMPYID Data Type CHAR(5) Attribute Definition Thehandled by company identifier is the company identifier of theadministrator or adjustor's who is handling the action item.

-   -   4.1.14 handling for adjustor code

Entity AUTHORIZATION ACTIVITY LOG Column Name handl_for_adjr_cde LabelName handling for adjustor code: System Name HNDADJRCDE Data TypeCHAR(10) Attribute Definition The handled by adjustor code is theadjustor code of an adjustor/user who is handling authorizationactivities for another adjustor/user in the ARMS Web application.

-   -   4.1.15 handling for company identifier

Entity AUTHORIZATION ACTIVITY LOG Column Name handl_for_cmpy_id LabelName handling for company identifier: System Name HNDCMPYID Data TypeCHAR(5) Attribute Definition The handling for company identifier is thecompany identifier used to uniquely identify an adjustor/user who ishandling authorization activities for another adjustor/user in the ARMSWeb application.

-   -   4.1.16 Insurance Claim Number

Entity ARM: Authorization(Claim Info) Column Name AZCLNO Label NameInsurance Claim Number System Name Data Type CHAR(20) AttributeDefinition

-   -   4.1.17 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.18 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.19 loss type description

Entity LOSS TYPE Column Name loss_typ_dsc Label Name loss typedescription: System Name LOSSTYPDSC Data Type CHAR(40) AttributeDefinition The loss type description is a lexical definition of the losstype code which defines the different loss categories when an InsuranceCompany authorizes a Rental. For example: Theft, Drivable, Repairable,Non-drivable, Non-repairable, Totaled.

-   -   4.1.20 NOTE

Entity ARM: ARMS/400 Diary Notes File Column Name NENOTE Label Name NOTESystem Name Data Type CHAR(50) Attribute Definition

-   -   4.1.21 Renters Day Phone Extension

Entity ARM: Renter Detail Column Name RKDYEX Label Name Renters DayPhone Extension System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.22 Renters Night Phone

Entity ARM: Renter Detail Column Name RKNTPH Label Name Renters NightPhone System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.23 Renters Night Phone Extension

Entity ARM: Renter Detail Column Name RKNTEX Label Name Renters NightPhone Extension System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.23 State

Entity ARM: Renter Detail Column Name RKSACD Label Name State SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.24 Zip Code

Entity ARM: Renter Detail Column Name RKZPCD Label Name Zip Code SystemName Data Type CHAR(9) Attribute Definition

5. Questions and Answers

-   -   Issue Number: 345    -   Question: Do we force the user to view the Rental Detail in        order to change the unassigned adjuster to an adjuster who is        authorized to handle?    -   Status: Closed—Resolved    -   Resolution: 4-12-00, Randy Haselhorst, we don't want to force        them to look at the detail to assign a rental request to another        user. They primarily look for claim number, claim type, renter        name and possibly date of loss. If you can make the option        you've described intuitive, that may work, but it doesn't sound        that way to me.    -   4-12-00, Kim De Valiance, NO—This is a great feature, but I        don't know if it is necessary. Some companies use this feature,        while others wait for the phone call to authorize.    -   Issue Number: 346    -   Question: Should you be allowed to decline, authorize or extend        an unassigned rental.    -   Status: Closed—Resolved    -   Resolution: 4-12-00, Randy Haselhorst—you can't “extend” until        you've authorized. Decline could be an option, but we should        probably think about that more to determine if we should.        Current state does not have this but I have heard people ask for        it. As far as authorizing, that again may be a good idea. I′d        like to see Kim and Dave's ideas.    -   4-12-00, Kim De Valiance—Yes, we have heard this many, many        times that will assigning a rental, the user should have the        ability to do all these things (as long as the user has the        proper authority).    -   Issue Number: 361    -   Question: Can we pass along an unassigned to another office?    -   Status: Pending    -   Resolution: Yes, if the request is an unassigned status, the        USER can transfer it to another office.    -   Issue Number: 378    -   Question: Can we Exit the use case after Sending a Message and        leave the request unassigned? Iteration 2 question.    -   Status: Closed—Resolved    -   Resolution: 6-23-00 Per Brian Weingart,—yes, after sending a        message on an unassigned request, if we didn't assign an        adjuster, it is still unassigned.    -   Issue Number: 413    -   Question: 6-23-00, Only one person can handle un-assigns—which        is set up in the profile? Or can a multiple # of people handle        the un-assigns? Does the Handling for drop down box allow for        the selection of unassigned? How do we handle record locking?        Per Jennifer, Sean is working on this issue.    -   Status: Pending    -   Resolution:    -   Issue Number: 414    -   Question: 6-23-00, If I select Unassigned from the action item        list and only one exists do I go straight to the detail? Per        Jennifer—Sean is working on this issue.    -   Status: Pending    -   Resolution:    -   Issue Number: 415    -   Question: 6-23-00, If I select Unassigned from the action item        list and multiple exists I go straight to the detail. I go to a        screen, which looks like action items, but list all of the        unassigned. Per Jennifer—Sean is working on this issue.    -   Status: Pending    -   Resolution:

Functional Design Specification Authorize a Request Version 1.1Authorize a Request 1. Authorize Request Use Case 1.1 Brief Description

-   -   This use case describes how a USER authorizes a direct bill        request.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:        -   ADJUSTER—The USER will use this system to authorize a direct            bill request.

1.3 Pre-Conditions

-   -   The USER must be logged into the ARMS Web system.    -   The USER must have the authority to authorize a request.    -   At least one outstanding unauthorized direct bill request must        be assigned that the USER may handle.    -   The USER must have selected an Unauthorized Direct Bill Request        from the Review Action Items Screen or from the Search Results        page.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps to make        changes and updates to “Authorize Request”.    -   1.4.1 Activity Diagram—see FIG. 117.    -   1.4.2 Basic Flow        -   1. The USER selects an outstanding direct bill to authorize.        -   2. The system displays the Customer file.        -   3. The USER reviews the renter's information.        -   4. The USER inputs a number of Authorized Amounts, days and            required fields.        -   5. The USER submits the Authorization.        -   6. The system validates information in the Customer File.        -   7. If the adjuster assigned to the Customer File is            ‘UNKNOWN’ or ‘UNASSIGNED’, the System will assign the            Customer File to the current USER.        -   8. The system will update the ARMS/Web database with the            Authorization.        -   9. The System reads the user profile to see if the            confirmation page should display.        -   10. If the profile indicates ‘Show Confirmation Page’, the            System will display the confirmation page.        -   11. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 View Notebook            -   At step 3 of the Basic Flow, the USER can select to view                the transaction history (Notebook) by selecting the Go                To Notebook link.        -   1.4.3.2 Add Notes to Customer File            -   At step 3 of the Basic Flow, the USER can add notes to                the Customer File by typing in the appropriate notes                field on the Customer File page.        -   1.4.3.3 Skip Customer File            -   At step 3 of the Basic Flow, the USER should have the                ability to skip to the next action item by clicking the                Skip button. After clicking the Skip button, the USER                should be taken to the next action item on their current                list without any changes to the file being skipped.        -   1.4.3.4 Change Customer File            -   At step 3 of the Basic Flow, the adjuster can make                changes to the additional details of the Customer File.                This is done by selecting the Add/Change link which will                invoke an editable page with all *appropriate                information editable.

1.5 Post-Conditions

-   -   If the use case was successful then the changes should go into        effect immediately and the screen should revert back to the        original screen of entry.    -   If the use case was successful, then the ARMS system will be        notified of authorization changes.    -   If the use case was unsuccessful then the system state will be        unchanged.

1.6 Special Requirements

-   -   1.6.1 Requirements for Claim Type Authorizations        -   The following are a set of requirements surrounding the type            of authorized amounts that are allowable based on the Claim            Type associated with a rental. These restrictions DO NOT            APPLY to reservations that are submitted with a Direct            Billing Percentage of zero (0).        -   1.6.1.1 When the Claim Type selected is ‘Insured, ‘Theft’,            or ‘Uninsured Motorist’            -   1.6.1.1.1 The reservation/rental must always include an                Authorized Rate or both Policy Daily and Maximum Limits                as defined by the renter's insurance policy. Zero (0) is                an acceptable Policy Daily Limit.            -   1.6.1.1.2 The reservation/rental must include an                Authorized Rate or Policy Daily Limit if a Policy                Maximum Limit is included. Zero (0) is an acceptable                Policy Daily Limit.        -   1.6.1.2 When the Claim Type selected is ‘Claimant’            -   1.6.1.2.1 The reservation/rental must always include an                Authorized Rate.            -   1.6.1.2.2 The reservation/rental may not include a                Policy Daily/Maximum Limits selection.        -   1.6.1.3 Requirements for editable fields based on            reservation/ticket status            -   1.6.1.3.1 Depending on the status of the Customer File                the adjuster may change the following fields:

Unassigned/ Assigned but Unauthorized Unauthorized Reservation/Reservation or Authorized Field Name Ticket Ticket Ticket CLAIM NUMBER XX X CLAIM TYPE X X X LOSS TYPE X X X DATE OF LOSS X X X INSURED X X XINFORMATION RENTER X INFORMATION DATE RENTAL IS X NEEDED ADDITIONAL X XX CHARGES NUMBER OF X X AUTHORIZED DAYS BILL-TO PERCENT X X X POLICYLIMITS X X X AUTHORIZED RATE X X X

-   -   -   If the Customer File is an Unauthorized Reservation, the            adjuster can Reject the Authorization Request, Send a            Message, and/or Transfer (Assign) the file to an adjuster.            -   1.6.1.3.2 If the status of the Customer File is an open                ticket the following rules apply:

Unauthorized Authorized Reservation/ Authorized Actions ReservationTicket Open Ticket Send Message X X X Extension X Terminate Rental XCancel Authorization X X Transfer/Assign Adjuster X X X View Car Class XX X

1.7 Extension Points

-   -   An extension point indicates a link between this use case and        another use case. Extension points associated with the use case        are indicated below. Clicking on the extension point will open        the related use case.    -   1.7.1 MA-04 Send Message        -   The Send Message will be used to allow the USER to capture            messages and diary notes associated with a rental            reservation/authorization. The USER can elect to either have            the message sent to the Enterprise rental branch location            responsible for the reservation/authorization, or to store            the note in the ARMS Web system without sending the message            to Enterprise. All MESSAGES and DIARY NOTES captured must be            related to a specific reservation/authorization.    -   1.7.2 MA-16 Transfer Work        -   (The Change Adjuster button invokes this use case).        -   The ADJUSTER may choose to transfer an authorization to a            different adjuster in his/her office or transfer the            authorization to another adjuster in a different office.    -   1.7.3 MA-08 View Car Class        -   The ADJUSTER may choose to view the car class. This button            invokes the View Car Class use case.    -   1.7.4 MA-17 Cancel Authorization        -   The ADJUSTER may choose to deny the authorization. When the            ADJUSTER selects the CANCEL button, it will invoke the            Cancel Authorization use case to reject the authorization.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Authorize Rental Detail

-   -   This screen will allow the user to work the currently selected        authorization request. The user may set the authorization        amounts and policy coverage limits or may assign the request to        another adjuster.    -   2.1.1 Screen Layout—Authorize Rental Detail—see FIG. 118.    -   2.1.2 Authorize Rental Detail

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleHandling For: List Box 30 Handling for First Name + Last N/A. Adjuster'sName Name Note to Input 0 Message NOTE Enterprise: Notebook Output 50Message NOTE Note to Self Input 0 Message NOTE Only Output 8 MessageCreation Add Date N/A. Date Message Output 50 Message Text NOTE N/A.Output 10 Notebook creation Add Date date Claim no. Output 30 ClaimNumber Insurance Claim Number Claim Number: Input 11 Claim NumberInsurance Claim N/A. Number    days @ Input 4 Number of Days Number OfDays N/A. Authorized Authorized Direct Bill %: Input 6 Percent CoveredBill To % N/A. Policy: Daily List Box 5 Policy Maximum and Dollars PerDay N/A. rate/Maximum Daily Rates Covered dollars: Policy: Daily ListBox 5 Policy Maximum and Max $ Covered N/A. rate/Maximum Daily Ratesdollars: Output 30 Rental Location Rental Location N/A. Branch Name DateRental List Box 10 Rental Start Date Start Date N/A. Needed: days @   List Box 6 Vehicle Rate Vehicle Rate N/A. Insured Name: Input 30Insured's Name First Name + Last N/A. Name Insured Name: Output 20Insured's Name First Name + Last Name Output 30 Rental Location AddressLine + N/A. Address Address Line2 Output 25 Rental Location City CityN/A. Name Output 10 Rental Location Zip Code N/A. Postal/Zip Code Output3 Rental Location State/ State N/A. Province Code Output 13 RentalLocation Telephone Number N/A. Telephone Number Date of Loss: List Box10 Date of Loss Date of Loss N/A. Date of Loss Output 10 Date of LossDate of Loss Output 30 Renter's Address Address Line Line Renter'sOutput 20 Renter's City City Address Output 3 Renter's StateState/Province Code Output 15 Renter's Zip/Postal Zip Code Code HomePhone: Output 16 Renter's Home Renters Night Phone + This field is inputif Phone Renters Night the ticket is not Phone Extension opened. It willnot be editable if the ticket is open. Authorize Output 30 Renter's NameFirst Name + Last N/A. Direct Bill: for Name Renter: Output 30 Renter'sName First Name + Last N/A. Name Output 16 Renter's Work Phone DayPhone + Renters Day Phone Extension Owner's Output 20 Vehicle Year, MakeRenter Vehicle Year + Vehicle and Model Renter Make/Model Output 15Repair Facility City City Repair Facility Output 20 Repair Facility NameRepair Facility Name Output 3 Repair Facility State State Output 10Repair Facility Telephone Number Telephone Number Output 7 RepairFacility Zip Zip Code Code Claim Type: List Box 15 Claim Type claim typeN/A. description Claims Office: Output 3 Office Id external organizationN/A. abbreviated name Vehicle List Box 20 Loss Type loss typedescription Condition Vehicle Output 20 Type of Loss loss typedescription Condition Input 20 Renter's Email renter email

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Skip            -   When clicked, the USER will be taken out of the use case                without changing the current status of the request. Any                changes made by clicking Change or Add and keying data                in the bottom section will be saved.        -   2.1.3.2 Process            -   When clicked, the system will validate the input and                accept the changes made to the customer file. The arms                database will be updated and the data will be sent to                the arms system. The use case will then end and the USER                will return to the process from which they came.        -   2.1.3.3 Notebook            -   When clicked, the USER will be taken to the Note Book                section at the bottom of the screen to view all messages                for this rental.        -   2.1.3.4 Transfer File            -   When clicked, the USER will be taken to the Transfer                File screen. This screen allows the USER to change the                office or adjuster currently assigned to the customer                file. The required information in the Extend                Rental/Customer File will be passed to the Transfer File                screen. Upon completion of the transfer, the USER will                then be returned to the next action item or the profiled                start page, depending on the screen from which the USER                began.        -   2.1.3.5 Change or Add            -   When clicked, the system will refresh the current screen                and make all editable fields in the bottom section                (outside the gray box area) input capable. The changes                on the top of the screen will not be lost.        -   2.1.3.6 Top of page            -   When clicked, the USER will be taken to the top of the                current page.        -   2.1.3.7 View Car Class            -   When clicked, the USER will be taken to the View Car                Class Use Case. No changes will be lost. Once the USER                is finished with this use case, the USER will return to                the Extend Rental Use Case.

3. Application Operations 4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 Add Date

Entity ARM: ARMS/400 Diary Notes File Column Name NEADDT Label Name AddDate System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.2 Address Line

Entity ARM: Renter Location Master Column Name LOADL1 Label Name SystemName Data Type CHAR(30) Attribute Definition

-   -   4.1.3 Address Line

Entity ARM: Renter Detail Column Name RKADL1 Label Name Address LineSystem Name Data Type CHAR(30) Attribute Definition

-   -   4.1.4 Address Line2

Entity ARM: Renter Location Master Column Name LOADL2 Label Name AddressLine System Name Data Type CHAR(30) Attribute Definition

-   -   4.1.5 Bill To %

Entity ARM: Authorization(Claim Info) Column Name AZBTPC Label Name BillTo % System Name Data Type DECIMAL(3) Attribute Definition

-   -   4.1.6 Branch

Entity A4 Cross Reference Column Name br_id Label Name Branch: SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.7 City

Entity ARM: Rental Location Master Column Name LOCYNM Label Name CitySystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.8 City

Entity ARM: Renter Detail Column Name RKCYNM Label Name City System NameData Type CHAR(20) Attribute Definition

-   -   4.1.9 City

Entity ARM: Repair Detail Column Name RUCYNM Label Name City System NameData Type CHAR(20) Attribute Definition

-   -   4.1.10 claim type code

Entity AUTHORIZATION EXTENSION Column Name clm_typ_cde Label Name claimtype code: System Name CLMTYPCDE Data Type DEC(3,0) Attribute The claimtype code defines the different Authorization Definition claim types.For example: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.11 claim type description

Entity CLAIM TYPE Column Name clm_typ_dsc Label Name claim typedescription: System Name CLMTYPDSC Data Type CHAR(40) Attribute Theclaim type description is a lexical definition of the Definition claimtype codewhich defines the different Authorization claim types. Forexample: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.12 company identifier

Entity EXTERNAL ORGANIZATION Column Name cmpy_id Label Name companyidentifier: System Name CMPYID Data Type DEC(11,0) Attribute BusinessParty Identifier is a surrogate key assigned to Definition each uniqueoccurrence of an Individual, External Organization, and InternalOrganization (Business Party).

-   -   4.1.13 Date of Loss

Entity ARM: Renter Detail Column Name RKLSDT Label Name Date Of LossSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.14 Day Phone

Entity ARM: Renter Detail Column Name RKDYPH Label Name Day Phone SystemName Data Type NUMERIC(10) Attribute Definition

-   -   4.1.15 Dollars Per Day Covered

Entity ARM: Authorization(Claim Info) Column Name AZ$PDY Label NameDollars Per Day Covered System Name Data Type DECIMAL(5,2) AttributeDefinition

-   -   4.1.16 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute External Organization Abbreviated Name is aDefinition shortened text based label associated with an organizationoutside of Enterprise. This name is sometimes used for accountingpurposes.

-   -   4.1.17 external organization identifier

Entity EXTERNAL ORGANIZATION Column Name e_o_id Label Name externalorganization identifier: System Name EOID Data Type DEC(11,0) AttributeThe external organization identifier is a surrogate key Definitionassigned to each unique occurrence of an External Organization.Examples: body shops, vehicle manufacturers, insurance companies,leasing accounts, credit unions, dealerships, or government agencies.

-   -   4.1.18 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.19 First Name

Entity ARM: Insured Detail Column Name IRFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.20 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.21 Group

Entity A4 Cross Reference Column Name grp_id Label Name Group NumberSystem Name Data Type CHAR(2) Attribute Definition

-   -   4.1.22 Insurance Claim Number

Entity ARM: Authorization(Claim Info) Column Name AZCLNO Label NameInsurance Claim Number System Name Data Type CHAR(20) AttributeDefinition

-   -   4.1.23 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.24 Last Name

Entity ARM: Insured Detail Column Name IRLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.25 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.26 loss type code

Entity AUTHORIZATION EXTENSION Column Name loss_typ_cde Label Name losstype code: System Name LOSSTYPCDE Data Type DEC(3,0) Attribute The losstype code defines the different loss categories Definition when anInsurance Company authorizes a Rental. For example: Theft, Drivable,Repairable, Non-drivable, Non-repairable, Totaled.

-   -   4.1.27 loss type description

Entity LOSS TYPE Column Name loss_typ_dsc Label Name loss typedescription: System Name LOSSTYPDSC Data Type CHAR(40) Attribute Theloss type description is a lexical definition of the loss Definitiontype code which defines the different loss categories when an InsuranceCompany authorizes a Rental. For example: Theft, Drivable, Repairable,Non-drivable, Non-repairable, Totaled.

-   -   4.1.28 Max $ Covered

Entity ARM: Authorization(Claim Info) Column Name AZ$MAX Label Name Max$ Covered System Name Data Type DECIMAL(9,2) Attribute Definition

-   -   4.1.29 NOTE

Entity ARM: ARMS/400 Diary Notes File Column Name NENOTE Label Name NOTESystem Name Data Type CHAR(50) Attribute Definition

-   -   4.1.30 Number Of Days Authorized

Entity ARM: Authorization(Claim Info) Column Name AZAUDY Label NameNumber Of Days Authorized System Name Data Type DECIMAL(3) AttributeDefinition

-   -   4.1.31 Rental Location

Entity ARM: Authorization(Claim Info) Column Name AZRNLC Label NameRental Location System Name Data Type CHAR(10) Attribute Definition

-   -   4.1.32 renter email

Entity RENTER EXTENSION Column Name rentr_eml Label Name renter email:System Name RENTREML Data Type CHAR(70) Attribute Definition The emailaddress of the renter.

-   -   4.1.33 Renter Make/Model

Entity ARM: Renter Detail Column Name RKVHMM Label Name RenterMake/Model System Name Data Type CHAR(15) Attribute Definition

-   -   4.1.34 Renter Vehicle Year

Entity ARM: Renter Detail Column Name RKVHYR Label Name Renter VehicleYear System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.35 Renters Day Phone Extension

Entity ARM: Renter Detail Column Name RKDYEX Label Name Renters DayPhone Extension System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.36 Renters Night Phone

Entity ARM: Renter Detail Column Name RKNTPH Label Name Renters NightPhone System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.37 Renters Night Phone Extension

Entity ARM: Renter Detail Column Name RKNTEX Label Name Renters NightPhone Extension System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.38 Repair Facility Name

Entity ARM: Repair Detail Column Name RURFNM Label Name Repair FacilityName System Name Data Type CHAR(35) Attribute Definition

-   -   4.1.39 Start Date

Entity ARM: Authorization(Claim Info) Column Name AZSTDT Label NameStart Date System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.40 State

Entity ARM: Rental Location Master Column Name LOSACD Label Name StateSystem Name Data Type CHAR(2) Attribute Definition

-   -   4.1.41 State

Entity ARM: Renter Detail Column Name RKSACD Label Name State SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.42 State

Entity ARM: Repair Detail Column Name RUSACD Label Name State SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.43 Status Description

Entity ARM: ARMS/400 Cross Reference Status Table File Column NameXUSTDS Label Name Status Description System Name Data Type CHAR(6)Attribute Definition

-   -   4.1.44 Telephone Number

Entity ARM: Rental Location Master Column Name LOPHNO Label NameTelephone Number System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.45 Telephone Number

Entity ARM: Repair Detail Column Name RUPHNO Label Name Telephone NumberSystem Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.46 Vehicle Class

Entity ARM: Authorization(Claim Info) Column Name AZVHCS Label NameVehicle Class System Name Data Type CHAR(2) Attribute Definition

-   -   4.1.47 Vehicle Rate

Entity ARM: Authorization(Claim Info) Column Name AZVHRT Label NameVehicle Rate System Name Data Type DECIMAL(5,2) Attribute Definition

-   -   4.1.48 Zip Code

Entity ARM: Rental Location Master Column Name LOZPCD Label Name ZipCode System Name Data Type CHAR(9) Attribute Definition

-   -   4.1.49 Zip Code

Entity ARM: Repair Detail Column Name RUZPCD Label Name Zip Code SystemName Data Type CHAR(9) Attribute Definition

5. Questions and Answers

-   -   Issue Number: 419    -   Question: 6-23-00, When rejecting an authorization do we want a        reason code? Per Jennifer—Mike, Brad and Craig is handling this.    -   Status: Pending    -   Resolution: 07-03-00—Brad Reel: In the ARMS Web V2.0 application        reason codes will be collected for the following events: reject        invoice, terminate authorization. Per a discussion with Randy        Haselhorst, it would be worthwhile to collect a reason code for        reject/cancel authorization. However, it is not critical for        this release. If possible it should be incorporated.    -   07-03-00—Brad Reel: I am reassigning to Mike Slater to work with        Neil Fitzgerald and determine whether or not to incorporate in        V2.0, or wait until a later release.

Functional Design Specification Change Customer File Version 1.1 ChangeCustomer File 1. Change Customer File Use Case 1.1 Brief Description

-   -   The Change Authorization use case describes how the USER could        change an authorization assigned to a reservation nor an open        rental.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:        -   ADJUSTER—The USER will use this case to add or change            information related to an existing Customer File on a rental            within ARMS Web.

1.3 Pre-Conditions

-   -   The USER must be logged into the ARMS Web system.    -   The USER must have selected to change an existing Customer File.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps to make        changes to a Customer File.    -   1.4.1 Activity Diagram—see FIG. 119.    -   1.4.2 Basic Flow        -   1. The USER will select a Customer File to change.        -   2. The SYSTEM will display the associated Customer File            detail of the selected item.        -   3. The USER will add additional or modify existing            information associated with the Customer File.        -   4. The SYSTEM will validate added or modified data.        -   5. The SYSTEM will update ARMS Web to reflect the changes.        -   6. The SYSTEM notifies ARMS of the changes associated with            the Customer File.        -   7. The SYSTEM checks the profile for the confirmation screen            setting.        -   8. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 View Rental Notebook            -   At step 1, the USER may choose to view the history of a                rental. The USER will be able to see the last five diary                notes. The USER can also select to view the transaction                history or add diary notes from the Extend Rental                Detail.        -   1.4.3.2 Validate Changes            -   If the USER changes or adds information, which does not                pass validation, an error message will notify the USER                and return them to step 1 of the Basic Flow.            -   If an error is discovered in the validation of the                reservation/rental information submitted by the USER                (Step 3 of the Basic Flow), the system would present the                USER with an error message and return them to the                Detailed Reservation/Rental Display. If the error is                specific to a data field within the form, the field                should be highlighted and the error described.        -   1.4.3.3 Display Confirmation            -   After step 6, the USER may wish to have a confirmation                page displayed, indicating that some type of change has                taken place. The confirmation page is completely                optional; therefore, at anytime the USER wants to set                their profile to bypass this screen, he/she may do so.        -   1.4.3.4 Update USER Profile            -   During the confirmation process, the USER has the option                of changing their profile setting to display or hide the                confirmation page. Each time the setting is changed, the                USER profile must be updated to reflect the new                requirements set by the USER.

1.5 Post-Conditions

-   -   If the use case was successful then the changes have been saved        to the ARMS Web database and if appropriate, ARMS Web has        generated notification transactions to ARMS.    -   If the use case was unsuccessful then the system has remained        unchanged.

1.6 Special Requirements

-   -   It will be considered invalid if for a reservation, the Claim        Number, Renter First Name, Renter Last Name, Claim Type, Vehicle        Condition, Rental Location, Authorized Number of Days, Direct        Bill Percent, and at least one Renter Telephone number have not        been included.    -   It will be considered invalid if the customer has established        Claim Number editing and the Claim Number format does not meet        the requirements of the customer's Claim Number definition.    -   It will be considered invalid if any field identified as        REQUIRED in the company/office profile is not included.    -   It will be considered invalid if any data entered violates the        data type as specified by the ARMS Web database (i.e., alpha        characters in a numeric field).    -   A warning will be presented to the USER if any defined limits        identified in the company/office/user profile are exceeded        (e.g., Maximum Number of Days Authorized). The system will allow        the USER to submit the authorization from the warning.    -   It will be considered invalid if the selected Claim Type is        ‘Insured,’ or ‘Theft’ and the reservation does not include an        Authorized Rate or does not include both Policy Daily and Policy        Maximum Limits (with the exception of reservations with a Direct        Bill Percent of zero (0)). A Policy Daily Limit of zero (0) is        an acceptable entry.    -   It will be considered invalid if the selected Claim Type is        ‘Insured,’ or ‘Theft’ and the reservation includes a Policy        Maximum Limit but does not include an Authorized Rate or Policy        Daily Limit (with the exception of reservations with a Direct        Bill Percent of zero (0)). A Policy Daily Limit of zero (0) is        an acceptable entry.    -   It will be considered invalid if the selected Claim Type is        ‘Claimant’ and Policy Limits (Daily or Maximum) have been        included.    -   It will be considered invalid if the Authorized Number of Days        is included and is less than zero (0).    -   It will be considered invalid if the Direct Bill Percent is        greater than zero (0) and the Authorized Number of Days is zero.    -   It will be considered invalid if the Direct Bill Percent is less        than zero (0).    -   It will be considered invalid if the Direct Bill Percent is        greater than one hundred (100).    -   It will be considered invalid if the Labor Hours are less than        zero (0).    -   It will be considered invalid if the Date of Loss is greater        than the current date.    -   It will be considered invalid if the first three digits (i.e.,        area code) of any U.S. or Canadian telephone number meet the        criteria below:        -   0XX        -   1XX        -   the second and third digits equal (e.g., 800, 877, 888,            etc.)    -   Where X equals any digit 0 through 9.    -   It will be considered invalid if a U.S. or Canadian telephone        number does not consist of 10 digits.    -   It will be considered invalid if a U.S. postal code that does        not consist of 5 or 9 digits.    -   It will be considered invalid if the a Canadian postal code does        not consist of 6 alphanumeric characters in the format AXAXAX        where A is an alpha character and X is a digit between 0 and 9.    -   It will be considered invalid if an E-mail address is included        that does not include an ‘@’ character.    -   It will be considered invalid if the Send e-mail Confirmation to        Renter flag is set to true and the Renter e-mail address is not        included.    -   If the customer file is in reservation status, the screen will        show a cancel button for the USER to cancel the authorization if        desired.    -   If the customer file is in open ticket status, the screen will        show the set last day button for the USER to terminate the        rental if desired.

1.7 Extension Points 1.7.1 MA-04 Send a Message

-   -   The Send Message will be used to allow the USER to capture        messages and diary notes associated with extending a rental. The        USER can elect to either have the message sent to the Enterprise        rental branch location responsible for the        reservation/authorization, or to store the note in the ARMS Web        system without sending the message to Enterprise. All MESSAGES        and DIARY NOTES captured must be related to a specific        reservation/authorization.    -   1.7.2 MA-16 Reassign USER or Office (The Transfer File button        invokes this use case)        -   After the extend rental detail is displayed, the USER may            choose to change the current office/USER. First, the USER            would select to change the current office/USER. Second, the            system would display a list of authorized offices/USERs.            Third, the USER would select a new office/USER.    -   1.7.3 MA-15 Terminate a Rental (Set Last Day)        -   After the extend rental detail is displayed, the USER may            choose to terminate the rental. If termination is selected,            the USER must enter a reason for the termination of the            rental. Termination means the insurance company is no longer            willing to pay for the rental. This function (button) is            only available for an open ticket. For reservation status,            the USER should see the Cancel button.    -   1.7.4 MA-17 Cancel Authorization        -   Before step 5 of the Basic Flow, the USER should have the            capability to cancel the authorization. Before the USER has            made changes that have been updated in the database and sent            to ARMS, the Cancel Authorization function (button) should            be available for reservation status. However, the USER            cannot perform the Cancel function on an open ticket. For an            open ticket, the Termination (Set Last Day) function            (button) is available.    -   1.7.5 MA-08 View Car Class        -   The View Car Class use case will be used to allow the USER            to view details about and select a car class to apply to a            reservation. Details will include the average number of            passengers and luggage items that can be served by a vehicle            in the specific car class. The car class selected by the            USER should be applied to the reservation.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Change Rental Detail

-   -   This screen (see FIGS. 120( a) and (b)) will allow the USER to        work the currently selected authorization request. The USER may        set the authorization amounts and policy coverage limits or may        assign the request to another adjuster.    -   2.1.1 Screen Layout—Change Rental Detail—see FIGS. 120( a) and        (b)    -   2.1.2 Change Rental Detail

Screen Specific Screen Label Type Size Screen Field Name Data Field NameRule Additional Output 15 Additional Charges Charges Handling For:Output 30 Handling for First Name + Last Last Name + First Adjuster'sName Name Name Note to Self Input 50 Message NOTE Only Messages: Output8 Message Creation Add Date N/A. Date Note to Input 50 Message Text NOTEN/A. Enterprise: Output 50 Message Text NOTE N/A. Claim Number: Output11 Claim Number Insurance Claim Number Days Output 2 Number of DaysNumber Of Days N/A. Authorized to Authorized Authorized Date:_additional Output 2 Number of Days to Number of Days to authorizedExtend Extend days Policy Limits List Box 5 Policy Maximum and Max $Covered + Dollars per day Dollars Per Day Covered Output 30 RentalLocation Rental Location Branch Name days @: List Box 6 Rental LocationRate Vehicle Rate N/A. Date of Rental Output 10 Rental Start Date StartDate N/A. Insured Name: Output 30 Insured's Name First Name + Last NameOutput 30 Rental Location Address Line + N/A. Address Address Line2Output 25 Rental Location City City N/A. Name Output 10 Rental LocationZip Code N/A. Postal/Zip Code Output 3 Rental Location State/ State N/A.Province Code Output 13 Rental Location Telephone Number N/A. TelephoneNumber Date of Loss: Output 10 Date of Loss Date of Loss Output 20Renter City Name City Output 10 Rental Postal/Zip Zip Code Code Output 3Renter State/ State Province Code Output 30 Renter Street Address LineAddress Home: Output 16 Renter's Home Renters Night Phone + Not editableif ticket Phone Renters Night is Open. Phone Extension Output 30Renter's Name First Name + Last Will not be editable if Name ticket isopen. First Name + Last Name Renter Output 30 Renter's Name First Name +Last N/A. Information: Name Work Phone: Output 16 Renter's Work PhoneDay Phone + Will not be able to Renters Day Phone edit if ticket isOpen. Extension Owner's Output 4 Vehicle Year, Make Renter Make/Model +vehicle: and Model Renter Vehicle Year Repair Facility: Output 20 BodyShop Name Repair Facility Name Input 16 Body Shop Phone Telephone NumberNumber Output 15 Repair Facility City City Output 3 Repair FacilityState State Output 7 Repair Facility zip Zip Code code Last Day Output10 Date rental is CALCULATED Calculated field. authorized authorizedthrough Populated with an Open Ticket only. Charges to Output 10 TotalCharges CALCULATED Date: Renter Type Output 10 Claim type claim typedescription Claims Office: Output 3 Office Id external organization N/A.abbreviated name Vehicle Output 15 Type of Loss loss type descriptionCondition Renter Email: Output 20 Renter's Email renter email Will notbe able to edit if ticket is Open.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Skip            -   When clicked, the USER will be taken out of the use case                without changing the current status of the request. Any                changes made by clicking Change or Add and keying data                in the bottom section will be saved.        -   2.1.3.2 Process            -   When clicked, the system will validate the input and                accept the changes made to the customer file. The arms                web database will be updated and the data will be sent                to the arms system. The use case will then end and the                USER will return to the process from which they came.        -   2.1.3.3 Notebook            -   When clicked, the USER will be taken to the Note Book                section at the bottom of the screen to view all messages                for this rental.        -   2.1.3.4 Set Last Day            -   When clicked, the system will terminate the rental. The                USER will be prompted to enter a termination date for                this rental. This coincides with the use case                MA-15—Terminate Rental.        -   2.1.3.5 Transfer File            -   When clicked, the USER will be taken to the Transfer                File screen. This screen allows the USER to change the                office or adjuster currently assigned to the customer                file. The required information in the Extend                Rental/Customer File will be passed to the Transfer File                screen. Upon completion of the transfer, the USER will                then be returned to the next action item or the profiled                start page, depending on the screen from which the USER                began.        -   2.1.3.6 Change or Add            -   When clicked, the system will refresh the current screen                and make all editable fields in the bottom section                (outside the gray box area) input capable. The changes                on the top of the screen will not be lost.        -   2.1.3.7 Top of page            -   When clicked, the USER will be taken to the top of the                current page.        -   2.1.3.8 View Car Class            -   When clicked, the USER will be taken to the View Car                Class Use Case. No changes will be lost. Once the USER                is finished with this use case, the USER will return to                the Extend Rental Use Case.        -   2.1.3.9 Extend Rental (checkbox)            -   When clicked and the process button is clicked, the                system will validate the input and accept the extension                AND any other changes made to the customer file. The                arms web database will be updated and the data will be                sent to the arms system. The use case will then end and                the USER will proceed to the next action item. (If                unchecked and the process button is clicked, only the                changes to the screen will be saved. The extension will                NOT be executed.)        -   2.1.3.10 Last Action Message            -   After each action item in the USER's list has been                completed, upon arriving at the next item there will be                a confirmation message at the top of the screen. This                message will be a hyperlink describing the last                completed action. If the USER clicks on this link, the                system will open the customer file, which will reflect                all of the current information for the rental. The USER                is then free to make additional changes or to simply                view the file.

3. Application Operations 4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 Add Date

Entity ARM: ARMS/400 Diary Notes File Column Name NEADDT Label Name AddDate System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.2 Address Line

Entity ARM: Renter Location Master Column Name LOADL1 Label Name SystemName Data Type CHAR(30) Attribute Definition

-   -   4.1.3 Address Line

Entity ARM: Renter Detail Column Name RKADL1 Label Name Address LineSystem Name Data Type CHAR(30) Attribute Definition

-   -   4.1.4 Address Line2

Entity ARM: Rental Location Master Column Name LOADL2 Label Name AddressLine System Name Data Type CHAR(30) Attribute Definition

-   -   4.1.5 Branch

Entity ARM: Rental Location Master Column Name Branch Label Name Branch:System Name Data Type CHAR(2) Attribute Definition

-   -   4.1.6 City

Entity ARM: Rental Location Master Column Name LOCYNM Label Name CitySystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.7 City

Entity ARM: Renter Detail Column Name RKCYNM Label Name City System NameData Type CHAR(20) Attribute Definition

-   -   4.1.8 City

Entity ARM: Repair Detail Column Name RUCYNM Label Name City System NameData Type CHAR(20) Attribute Definition

-   -   4.1.9 claim type code

Entity AUTHORIZATION EXTENSION Column Name clm_typ_cde Label Name claimtype code: System Name CLMTYPCDE Data Type DEC(3,0) Attribute DefinitionThe claim type code defines the different Authorization claim types. Forexample: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.10 claim type description

Entity CLAIM TYPE Column Name clm_typ_dsc Label Name claim typedescription: System Name CLMTYPDSC Data Type CHAR(40) AttributeDefinition The claim type description is a lexical definition of theclaim type code which defines the different Authorization claim types.For example: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.11 company identifier

Entity EXTERNAL ORGANIZATION Column Name cmpy_id Label Name companyidentifier: System Name CMPYID Data Type DEC(11,0) Attribute DefinitionBusiness Party Identifier is a surrogate key assigned to each uniqueoccurrence of an Individual, External Organization, and InternalOrganization (Business Party).

-   -   4.1.12 Date of Loss

Entity ARM: Renter Detail Column Name RKLSDT Label Name Date Of LossSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.13 Day Phone

Entity ARM: Renter Detail Column Name RKDYPH Label Name Day Phone SystemName Data Type NUMERIC(10) Attribute Definition

-   -   4.1.14 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute Definition External Organization Abbreviated Name isa shortened text based label associated with an organization outside ofEnterprise. This name is sometimes used for accounting purposes.

-   -   4.1.15 external organization identifier

Entity EXTERNAL ORGANIZATION Column Name e_o_id Label Name externalorganization identifier: System Name EOID Data Type DEC(11,0) AttributeDefinition The external organization identifier is a surrogate keyassigned to each unique occurrence of an External Organization.Examples: body shops, vehicle manufacturers, insurance companies,leasing accounts, credit unions, dealerships, or government agencies.

-   -   4.1.16 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.17 First Name

Entity ARM: Insured Detail Column Name IRFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.18 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.19 Group

Entity ARM: Rental Location Master Column Name Group Label Name GroupNumber System Name Data Type CHAR(2) Attribute Definition

-   -   4.1.20 Insurance Claim Number

Entity ARM: Authorization(Claim Info) Column Name AZCLNO Label NameInsurance Claim Number System Name Data Type CHAR(20) AttributeDefinition

-   -   4.1.21 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.22 Last Name

Entity ARM: Insured Detail Column Name IRLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.23 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.24 loss type code

Entity AUTHORIZATION EXTENSION Column Name loss_typ_cde Label Name losstype code: System Name LOSSTYPCDE Data Type DEC(3,0) AttributeDefinition The loss type code defines the different loss categories whenan Insurance Company authorizes a Rental. For example: Theft, Drivable,Repairable, Non-drivable, Non-repairable, Totaled.

-   -   4.1.25 loss type description

Entity LOSS TYPE Column Name loss_typ_dsc Label Name loss typedescription: System Name LOSSTYPDSC Data Type CHAR(40) AttributeDefinition The loss type description is a lexical definition of the losstype code which defines the different loss categories when an InsuranceCompany authorizes a Rental. For example: Theft, Drivable, Repairable,Non-drivable, Non-repairable, Totaled.

-   -   4.1.26 message ecars indicator

Entity AUTHORIZATION MESSAGE Column Name msg_ecars_ind Label Namemessage ecars indicator: System Name MSGECARIND Data Type CHAR(1)Attribute Definition The message ecars indicator indicates whether themessage is sent/received from the ecars system.

-   -   4.1.27 NOTE

Entity ARM: ARMS/400 Diary Notes File Column Name NENOTE Label Name NOTESystem Name Data Type CHAR(50) Attribute Definition

-   -   4.1.28 Number Of Days Authorized

Entity ARM: Authorization(Claim Info) Column Name AZAUDY Label NameNumber Of Days Authorized System Name Data Type DECIMAL(3) AttributeDefinition

-   -   4.1.29 Rate Charged

Entity ARM: Authorization(Claim Info) Column Name AZRTCH Label Name RateCharged System Name Data Type DECIMAL(5,2) Attribute Definition

-   -   4.1.30 Rental Location

Entity ARM: Authorization(Claim Info) Column Name AZRNLC Label NameRental Location System Name Data Type CHAR(10) Attribute Definition

-   -   4.1.31 renter email

Entity RENTER EXTENSION Column Name rentr_eml Label Name renter email:System Name RENTREML Data Type CHAR(70) Attribute Definition The emailaddress of the renter.

-   -   4.1.32 Renter Make/Model

Entity ARM: Renter Detail Column Name RKVHMM Label Name RenterMake/Model System Name Data Type CHAR(15) Attribute Definition

-   -   4.1.33 Renter Vehicle Year

Entity ARM: Renter Detail Column Name RKVHYR Label Name Renter VehicleYear System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.34 Renters Day Phone Extension

Entity ARM: Renter Detail Column Name RKDYEX Label Name Renters DayPhone Extension System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.35 Renters Night Phone

Entity ARM: Renter Detail Column Name RKNTPH Label Name Renters NightPhone System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.36 Renters Night Phone Extension

Entity ARM: Renter Detail Column Name RKNTEX Label Name Renters NightPhone Extension System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.37 Repair Facility Name

Entity ARM: Repair Detail Column Name RURFNM Label Name Repair FacilityName System Name Data Type CHAR(35) Attribute Definition

-   -   4.1.38 standard message description

Entity STANDARD MESSAGE Column Name std_msg_dsc Label Name standardmessage description: System Name STDMSGDSC Data Type CHAR(50) AttributeDefinition The standard message description is a lexical definition forstandard message code which defines a predefined message which isapplicable to specific activity type codes. For example: “Authorizationconfirmed on &Date with Reservation Number &Resnumber”

-   -   4.1.39 Start Date

Entity ARM: Authorization(Claim Info) Column Name AZSTDT Label NameStart Date System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.40 State

Entity ARM: Rental Location Master Column Name LOSACD Label Name StateSystem Name Data Type CHAR(2) Attribute Definition

-   -   4.1.41 State

Entity ARM: Renter Detail Column Name RKSACD Label Name State SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.42 State

Entity ARM: Repair Detail Column Name RUSACD Label Name State SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.43 Status Description

Entity ARM: ARMS/400 Cross Reference Status Table File Column NameXUSTDS Label Name Status Description System Name Data Type CHAR(6)Attribute Definition

-   -   4.1.44 Telephone Number

Entity ARM: Rental Location Master Column Name LOPHNO Label NameTelephone Number System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.45 Telephone Number

Entity ARM: Repair Detail Column Name RUPHNO Label Name Telephone NumberSystem Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.46 Vehicle Class

Entity ARM: Authorization(Claim Info) Column Name AZVHCS Label NameVehicle Class System Name Data Type CHAR(2) Attribute Definition

-   -   4.1.47 Vehicle Rate

Entity ARM: Authorization(Claim Info) Column Name AZVHRT Label NameVehicle Rate System Name Data Type DECIMAL(5,2) Attribute Definition

-   -   4.1.48 Zip Code

Entity ARM: Rental Location Master Column Name LOZPCD Label Name ZipCode System Name Data Type CHAR(9) Attribute Definition

-   -   4.1.49 Zip Code

Entity ARM: Repair Detail Column Name RUZPCD Label Name Zip Code SystemName Data Type CHAR(9) Attribute Definition

-   -   4.1.50 Zip Code

Entity ARM: Repair Detail Column Name RUZPCD Label Name Zip Code SystemName Data Type CHAR(9) Attribute Definition

5. Questions and Answers

-   -   Issue Number: 368    -   Question: Can the Adjuster shorten the number of days authorized        without terminating the rental.    -   Status: Closed—Resolved    -   Resolution: 5-3-00, Brian Weingart, Kim De Valiance—No. After a        ticket is open and has been authorized, the only modification        allowed to the number of days authorized comes in the form of a        termination. For example, if an adjuster sent us ten days and on        the fifth day, decided to only give us a total of six (thereby        removing the authorization for four days) the adjuster would        have to terminate that rental as of the sixth day.    -   Issue Number: 386    -   Question: Should the Date of Loss be editable in Change        Authorization or does it depend on the state of the        reservation/ticket.    -   Status: Closed—Resolved    -   Resolution: 6-23-00, Brian Weingart,—Since Date of Loss is        considered Insurance company information, the adjuster owns this        information. The Adjuster can change this in either a        reservation or open ticket status. This is editable until the        rental is considered closed.

Functional Design Specification Terminate Rental Version 1.0 TerminateRental 1. Terminate Rental Use Case 1.1 Brief Description

-   -   The Terminate Rental use case describes how the USER would        terminate a rental. This use case will allow the USER to inform        Enterprise of the last day that the ADJUSTER will pay for a        rental. In most cases, by providing a date in the future,        Enterprise will receive an extension through the last day.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:        -   ADJUSTER—The USER will use this case to terminate a rental.

1.3 Pre-Conditions

-   -   The USER must be logged into the ARMS Web system.    -   The USER must have the authority to terminate an open rental.    -   The USER must have selected an authorized rental.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps to terminate        a rental.    -   14.1 Activity Diagram—see FIG. 121.    -   14.2 Basic Flow        -   1. The USER selects to terminate an authorization.        -   2. The system prompts the USER for the termination            information.        -   3. The USER enters the termination date and reason/comments.        -   4. The USER submits the termination information.        -   5. The system will validate the termination information.        -   6. The system updates the ARMS Web database.        -   7. The system reads the USER profile for the confirmation            settings.        -   8. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Previous            -   After step 3, the USER can abandon all changes, which                result in the system state remaining unchanged. After                clicking the “Previous” button, the USER will be                returned to the screen from which they came.        -   1.4.3.2 Additional Comments            -   When terminating a rental, the USER must select a reason                from the drop-down box to explain why the termination is                taking place. As well, if further explanation is desired                there is a comment box in which the USER may enter                additional comments for more clarification. This section                is optional, unless the USER selects “Other” from the                reason code drop-down box. In this case, the comment box                must be used.        -   1.4.3.3 Display Confirmation            -   After step 7, the USER may wish to have a confirmation                page displayed, indicating that some type of change has                taken place. The confirmation page is completely                optional; therefore, at anytime the USER wants to set                their profile to bypass this screen, he/she may do so.        -   1.4.3.4 Update USER Profile            -   During the confirmation process, the USER has the option                of changing their profile setting to display or hide the                confirmation page. Each time the setting is changed, the                USER profile must be updated to reflect the new                requirements set by the USER.

1.5 Post-Conditions

-   -   If the use case was successful then the changes will go into        effect immediately and write a transaction record to pass to        ARMS indicating that there was a change on the rental. If the        renter's email address was entered, a system-generated message        will notify the renter.    -   If the use case was unsuccessful then the system will remain        unchanged.

1.6 Special Requirements

-   -   1.6.1 The termination date must be greater than or equal to the        current date or the last day authorized. There is a business        rule that ensures that an adjuster cannot take away already used        rental days.

Current Date Authorization Date Termination Date 6/20 6/25 >=6/20 6/206/10 >=6/10

-   -   1.6.2 If the USER extends an authorization that has been        terminated, the termination information is considered invalid.    -   1.6.3 It is mandatory that a USER select a termination reason        from the drop-down list. If the USER selects “Other” from the        drop-down list, a comment about the termination must be        supplied.

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Terminate Rental

-   -   This screen (see FIG. 122) will allow the user enter the        information about terminating a rental.    -   2.1.1 Screen Layout—Terminate Rental—see FIG. 122    -   2.1.2 Terminate Rental

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleComment: Input 50 Message Text NOTE Required field if Reason selected is“other” Reason: List Box 30 Reason NOTE Required Field Termination ListBox 10 Termination Date Termination Date The date entered Date must bethe current date or later. This is the date that the insurance companywill no longer pay for the rental. /This field should have a calendarcontrol associated with it to allow the user to select the date of lossfrom a calend. Renter: Output 30 Renter's Name First Name + LastRenter's Last Name + Name Renter's First Name

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Previous            -   Will return the user to the detail screen from which                they came. The system and the information on the detail                screen will remain unchanged.        -   2.1.3.2 Process            -   When clicked, the system will complete the termination                of the rental and notify the required parties.            -   2.1.3.2.1 The user must have selected a valid                termination date that is greater than the current date.

3. Application Operations 4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 Company Id

Entity ARM: ARMS/400 Internal Error Log File Column Name E4CUID LabelName Company Id System Name Data Type CHAR(5) Attribute Definition

-   -   4.1.2 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute External Organization Abbreviated Name is aDefinition shortened text based label associated with an organizationoutside of Enterprise. This name is sometimes used for accountingpurposes.

-   -   4.1.3 external organization identifier

Entity EXTERNAL ORGANIZATION Column Name e_o_id Label Name externalorganization identifier: System Name EOID Data Type DEC(11,0) AttributeThe external organization identifier is a surrogate key Definitionassigned to each unique occurrence of an External Organization.Examples: body shops, vehicle manufacturers, insurance companies,leasing accounts, credit unions, dealerships, or government agencies.

-   -   4.1.4 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.5 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.6 Insurance Claim Number

Entity ARM: Authorization(Claim Info) Column Name AZCLNO Label NameInsurance Claim Number System Name Data Type CHAR(20) AttributeDefinition

-   -   4.1.7 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.8 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.9 NOTE

Entity ARM: ARMS/400 Diary Notes File Column Name NENOTE Label Name NOTESystem Name Data Type CHAR(50) Attribute Definition

-   -   4.1.10 renter email

Entity RENTER EXTENSION Column Name rentr_eml Label Name renter email:System Name RENTREML Data Type CHAR(70) Attribute Definition The emailaddress of the renter.

-   -   4.1.11 Termination Date

Entity ARM: Authorization(Claim Info) Column Name AZTMDT Label NameTermination Date System Name Data Type NUMERIC(8) Attribute Definition

5. Questions and Answers

-   -   Issue Number: 373    -   Question: How is the renter currently notified of a termination        of the rental? Are they usually notified by the time the rental        is terminated? How should this be represented on the screen?        Should the checkbox say to notify the renter or that the renter        has already been notified?    -   Status: Pending    -   Resolution:

Functional Design Specification Transfer File Version 0.6 TransferFile 1. Transfer File Use Case 1.1 Brief Description

-   -   The Transfer File use case describes how the user would assign        one of their action items to another user/office.

1.2 Use Case Actors

-   -   The following actors will interact with this use case. Each of        the actors can be defined generically as USER. The USER will use        this use case to reassign action items to other USERS and/or        offices.        -   ADJUSTER        -   PROCESSOR

1.3 Pre-Conditions

-   -   The USER must be logged into the ARMS Web system.    -   The USER must have the ability to reassign action items.    -   The USER must have access to a customer file to reassign.    -   The customer file must be in an open, reservation, or        unauthorized state.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps for a USER        to reassign action items.    -   1.4.1 Activity Diagram—see FIG. 123.    -   1.4.2 Basic Flow        -   1. The USER selects to reassign a customer file.        -   2. The system retrieves the list of valid offices to            display.        -   3. The system retrieves the list of valid USERs to display            based on reservation/ticket status.        -   4. The system displays the list of adjusters for the current            office and the list of other valid offices.        -   5. The USER selects the user that will be the new owner of            the selected action item.        -   6. The system will update the ARMS Web database to reflect            the recent ownership change and changes, if any, from the            prior screen.        -   7. The system generates a message indicating that a transfer            and any other changes have been completed.        -   8. The system updates the ARMS Web database and notifies            ARMS with an Authorization Change transaction.        -   9. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Change Office            -   After step 3 of the basic flow, the USER may choose to                assign the action item to a new office. If the USER                chooses a new office, the flow would return to step 2 of                the basic flow. This should reflect possible recipients                of the action item from that office.        -   1.4.3.2 Cancel Use Case            -   The USER may cancel the use case at any point prior to                updating the ARMS Web Database. If the USER elects to                cancel the use case, the customer file will not be                transferred, however, any other changes that were made                to the file will remain.        -   1.4.3.3 Display Confirmation            -   After step 7, the USER may wish to have a confirmation                page displayed, indicating that some type of change has                taken place. The confirmation page is completely                optional, therefore, at anytime the USER wants to set                their profile to bypass this screen, he/she may do so.        -   1.4.3.4 Update USER Profile            -   During the confirmation process, the USER has the option                of changing their profile setting to display or hide the                confirmation page. Each time the setting is changed, the                USER profile must be updated to reflect the new                requirements set by the USER.

1.5 Post-Conditions

-   -   If the use case was successful then the changes should go in to        effect immediately and the new owner should be able to view the        newly assigned action item.    -   If the use case was unsuccessful then the system will remain        unchanged.

1.6 Special Requirements

-   -   When building the list of valid USERS, the system will determine        the status of the reservation/ticket and retrieve all users in        the current office with authority to process that status of a        reservation/ticket.    -   When building the list of valid Offices, the system will        retrieve all other offices defined within ARMS Web as valid        offices for the specified company.    -   When selecting an office for the reassign operation, the system        must rebuild the user list so the USER will only see valid users        that are able to complete the action item to be transferred.    -   After the changes have been submitted, the next Action Item will        populate indicating that a transfer has been completed, if the        USER started from the Action Item List.    -   After the changes have been submitted, the USER will return to        the profiled start page with a message indicating that a        transfer has been completed, if the USER arrived at the customer        file via the search option.

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Transfer File

-   -   This screen (see FIG. 124) will allow the USER to pick which        functions that they may want to change.    -   2.1.1 Screen Layout—Transfer File—see FIG. 124    -   2.1.2 Transfer File

Screen Label Type Size Screen Field Name Data Field Name Screen SpecificRule Adjuster's ListBox 30 Change to Adjuster's First Name + Last Listof adjuster's within Name Name Name the currently selected Assign toClaim Office that are authorized to handle the current request type. Theadjuster that the request is currently assigned to will be selected uponentry into the screen. Adjuster's Output 30 Current Adjuster's FirstName + Last N/A. Name: Name Name Claims Office ListBox 3 Change toOffice Id external List of office within the organization currentCompany identifier Structure that are authorized to handle the currentrequest type. The office that the request is currently assigned to willbe selected in the drop down box upon entry into the screen. ClaimsOffice: Output 3 Current Office Id external N/A organization abbreviatedname

-   -   2.1.3 Screen Function Definition        -   2.1.3.1 Cancel            -   When clicked, the USER will be returned to the                screen/use case where they were prior to selecting                Change Office/Adjuster (Transfer). Any changes made will                be lost and the system will remain unchanged.        -   2.1.3.2 Process            -   When clicked, the system will be validated. If the                validation passes, the update will be sent to the ARMS                system and the USER will be returned to the screen/use                case from which they came. If the validation fails, the                USER will be returned to the current screen with error                message(s) and the field in error highlighted.

3. Application Operations 4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute Definition External Organization Abbreviated Name isa shortened text based label associated with an organization outside ofEnterprise. This name is sometimes used for accounting purposes.

-   -   4.1.2 external organization identifier

Entity EXTERNAL ORGANIZATION Column Name e_o_id Label Name externalorganization identifier: System Name EOID Data Type DEC(11, 0) AttributeDefinition The external organization identifier is a surrogate keyassigned to each unique occurrence of an External Organization.Examples: body shops, vehicle manufacturers, insurance companies,leasing accounts, credit unions, dealerships, or government agencies.

-   -   4.1.3 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.4 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

Functional Design Specification Cancel Authorization Version 1.0 CancelAuthorization 1. Cancel Authorization Use Case 1.1 Brief Description

-   -   This use case will describe how a USER would cancel an        authorized reservation.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:    -   ADJUSTER—The USER will be able to perform the duties of        canceling an authorized reservation.

1.3 Pre-Conditions

-   -   The USER must be logged into the ARMS Web system.    -   The USER must have the ability to cancel an authorization.    -   The USER has selected an authorized reservation and wants to        cancel the authorization within ARMS Web.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps to “Cancel        Authorization”.    -   1.4.1 Activity Diagram—see FIG. 125.    -   1.4.2 Basic Flow        -   1. The USER selects to cancel the authorization.        -   2. The system will prompt the user for a reason for            cancellation.        -   3. The USER will select a reason.        -   4. The USER will submit the cancellation.        -   5. The system will update the ARMS Web database to reflect            that the USER cancelled the Authorization.        -   6. The system will read the USER profile for the            confirmation settings.        -   7. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Previous            -   After step 3, the USER can abandon all changes, which                result in the system state remaining unchanged. After                clicking the “Previous” button, the USER will be                returned to the screen from which they came.        -   1.4.3.2 Additional Comments            -   When canceling a rental, the USER must select a reason                from the drop-down box to explain why the cancellation                is taking place. As well, if further explanation is                desired, there is a comment box in which the USER may                enter additional comments for more clarification. This                section is optional, unless the USER selects “Other”                from the reason code drop-down box. In this case, the                comment box must be used.        -   1.4.3.3 Display Confirmation            -   After step 6, the USER may wish to have a confirmation                page displayed, indicating that some type of change has                taken place. The confirmation page is completely                optional, therefore, at anytime the USER wants to set                their profile to bypass this screen, he/she may do so.        -   1.4.3.4 Update USER Profile            -   During the confirmation process, the USER has the option                of changing their profile setting to display or hide the                confirmation page. Each time the setting is changed, the                USER profile must be updated to reflect the new                requirements set by the USER.

1.5 Post-Conditions

-   -   If the use case was successful then the changes should go in to        effect immediately and generate a transaction record to pass to        ARMS indicating that the authorized reservation was cancelled.    -   If the use case was unsuccessful then the system will remain        unchanged.

1.6 Special Requirements

-   -   When canceling an authorization, the USER must select a reason        from the drop-down list. If the USER chooses “Other” from the        pre-defined list, a comment about why the authorization was        cancelled must be supplied.

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Cancel Direct Bill Authorization

-   -   This screen (see FIG. 126) will allow the USER to pick which        functions that he/she may want to change.    -   2.1.1 Screen Layout—Cancel Direct Bill Authorization—see FIG.        126    -   2.1.2 Cancel Direct Bill Authorization

Screen Screen Label Type Size Screen Field Name Data Field Name SpecificRule Reason List Box 50 Cancellation Reason NOTE N/A Comment: Input 50Message Text NOTE Required if cancellation reason is “Other” Claim #Output 30 Claim Number Insurance Claim Number Renter's Name Output 30Renter's Name First Name + Last N/A Name

-   -   2.1.3 Screen Function Definition    -   This section includes the definitions for all functions that can        be performed within the screen. This includes operations invoked        by button clicks, specific shortcut keystrokes, or other actor        activity.        -   2.1.3.1 Previous            -   When clicked, the user will be returned to the                screen/use case where they were prior to selecting                Cancel Reservation. Any changes made will be lost and                the system will remain unchanged.        -   2.1.3.2 Process            -   When clicked, the system will update the message file                with the comment record if entered and mark the current                reservation authorization as cancel. The cancellation                and the new message, if entered, will be forwarded to                the ARMS system. The system returns the USER to the                appropriate Action Items List screen.

3. Application Operations 4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 Cancel Date

Entity ARM: Authorization(Claim Info) Column Name AZCNDT Label NameCancel Date System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.2 Cancellation Code

Entity ARM: Authorization(Claim Info) Column Name AZCNCD Label NameCancellation Code System Name Data Type CHAR(2) Attribute Definition

-   -   4.1.3 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute Definition External Organization Abbreviated Name isa shortened text based label associated with an organization outside ofEnterprise. This name is sometimes used for accounting purposes.

-   -   4.1.4 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.5 Insurance Claim Number

Entity ARM: Authorization(Claim Info) Column Name AZCLNO Label NameInsurance Claim Number System Name Data Type CHAR(20) AttributeDefinition

-   -   4.1.6 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.7 NOTE

Entity ARM: ARMS/400 Diary Notes File Column Name NENOTE Label Name NOTESystem Name Data Type CHAR(50) Attribute Definition

-   -   4.1.8 Rental Location

Entity ARM: Authorization(Claim Info) Column Name AZRNLC Label NameRental Location System Name Data Type CHAR(10) Attribute Definition

5. Questions and Answers

-   -   Issue Number: 418    -   Question: Do we need a reason to cancel—have cancel page.    -   Status: Closed—Resolved    -   Resolution: 6-23-00, Per Neil, kill this page, it's not        necessary.

Functional Design Specification View Customer File Version 1.0 ViewCustomer File 1. Search and View Customer File 1.1 Brief Description

-   -   This use case describes the process that a USER would use to        find and view information regarding a rental. In order to view        the rental detail, one of two general conditions must be        satisfied:    -   1) The rental is open and the USER does not have any authority        to make changes.    -   2) The rental is in a state that no longer allows changes to be        made.    -   If these conditions are not met, the USER will be taken to the        appropriate use case.

1.2 Use Case Actors

-   -   All actors will use the use case to View Rental Detail in the        ARMS Web system. All of the following actors can be defined        generically as a USER:        -   ADJUSTER        -   PROCESSOR        -   COMPANY MANAGER        -   ENTERPRISE ADMINISTRATOR        -   COMPANY ADMINISTRATOR

1.3 Pre-Conditions

-   -   The USER must be signed-on to the system    -   (AND)    -   The USER does not have the authority to make changes and the        ticket is open,    -   (OR)    -   The ticket is in a state that doesn't allow changes to be made.

1.4 Flow of Events

-   -   The Flow of Events includes all the steps necessary to View        Rental Detail in the ARMS Web system.    -   1.4.1 Activity Diagram—see FIG. 127.    -   1.4.2 Basic Flow        -   The Basic Flow of the View Rental Detail use case includes            all of the required activities for the USER to successfully            find and view information regarding an open rental.        -   1. The USER initiates a search for a Customer File.        -   2. The system, based on criteria entered by the USER,            retrieves the matches for that search.        -   3. The system displays the search results.        -   4. The USER selects one of the matches.        -   5. The system displays the detail of the Customer File.        -   6. This ends this use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Search Again            -   After step 3 of the basic flow, the USER may decide that                they would like to conduct another search. By entering                new search criteria, they would return to step 2 with                new criteria and the use case could continue.        -   1.4.3.2 Only One Match Found            -   At step 2 of the basic flow, if the system only finds                one match, the system will advance to step 5 of the                basic flow invoking the appropriate use case for                modifications.        -   1.4.3.3 View Only            -   If the Customer File selected was in a state not                allowing changes, the system would display the Customer                File, however, not allowing the USER to modify any                information within ARMS Web.

1.5 Post-Conditions

-   -   If the use case is successful, the system will return to its        previous state.    -   If the use case is unsuccessful, the use case the system will        remain unchanged.

1.6 Special Requirements

-   -   To successfully locate a customer file, the following criteria        must be satisfied:    -   1. The following fields will limit the search results: Adjuster        Name, Last Authorized Day, Date of Loss, and/or a status of the        Customer File.        -   a. If a Renter Last Name has been supplied, an exact match            on last name is considered valid.        -   b. If a Renter Last Name and Renter First Name has been            supplied and there is no exact match on Renter Last Name,            there is no match.        -   c. If a Renter Last Name and Renter First Name has been            supplied and there is an exact match on Renter Last Name and            not an exact match on Renter First Name, the Renter Last            Name with the closest Renter First Name is considered a            match.        -   d. If a Renter Last Name and Claim Number has been supplied            and there is an exact match on Renter Last Name and not on            Claim Number, the closest match on Renter Last Name and the            closest match on Claim Number greater than the Claim Number            provided is considered a match.    -   2. If the USER supplies one or more of the following fields, the        above result set will position to closest match of Customer        Files based on: Renter Last Name, Renter First Name, and/or        Claim Number.    -   3. This search capability will include all available Open and        Closed Rentals for searching.    -   4. Any empty fields signify the search should not limit the        result set by that field.    -   5. Any Customer File present in the result set will contain a        link to the appropriate use case based on the current status of        the reservation or rental.

1.7 Extension Points

-   -   1.7.1.1 MA-10 Authorized a Request        -   If the customer file were an unauthorized reservation or            ticket, the system would enter the Authorization use case to            allow the USER to authorize this Customer File.    -   1.7.1.2 MA-12 Extend Rental        -   If the customer file were an authorized ticket or an action            item of extension status, the system would enter the Extend            Rental use case to allow the USER to extend this Customer            File.    -   1.7.1.3 MA-13 Change Authorization        -   If the customer file were an authorized reservation or            ticket not requiring any immediate action, the system would            enter the Change Authorization use case to allow the USER to            authorize this Customer File.    -   1.7.1.4 MA-07 Additional Charges        -   The Additional Charges use case will be used to add special            charges to the reservation being created by the USER (e.g.,            CDW). Any Additional Charges captured should be returned and            applied to the reservation. The existence of Additional            Charges should be reflected on the reservation screen.    -   1.7.1.5 MA-08 View Car Class        -   The View Car Class use case will be used to allow the USER            to view details about and select a car class to apply to a            reservation. Details will include the average number of            passengers and luggage items that can be served by a vehicle            in the specific car class. The car class selected by the            USER should be applied to the reservation.    -   1.7.1.6 Invoicing—81-01-Handle Unapproved Invoices & BI-02 Pay        Approved Invoices & BI-03 Reject an Invoice        -   At step 5, the USER may elect to view approved invoices,            unapproved invoices, or rejected invoices. Upon completion            of this process, the USER should be returned back to step 5            of the Basic Flow.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.        2.1 Find a Customer (tab)    -   This screen will allow the USER to view the rental.    -   2.1.1 Find a Customer (tab)—see FIG. 128    -   2.1.2 Customer (tab)

Screen Screen Screen Data Specific Label Type Size Field Name Field NameRule last name Input 20 Renter last name Last name first name Input 20Renter's first name First name claim Input 30 Insurance claim Ins. ClaimN/A. number number number adj. last Input 20 Adjuster's Last name N/A.name last name last date Input 20 Last date LAST N/A. authorized:authorized AUTH DAY status: List Box 20 Contract Status Status Code N/A.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Search            -   When clicked, the will search for any records that match                the criteria listed.

2.2 Customer File—Closed Items

-   -   This screen will allow the USER to view the rental when closed.    -   2.2.1 Screen Layout—Customer File—Closed Items—see FIG. 129    -   2.2.2 Customer File—Closed Items

Screen Screen Label Type Size Screen Field Name Data Field Name SpecificRule Actual Days: Output 3 actual days rented Item Quantity InvoicingSection Only @ Output 3 Actual Rate Rented Item Rate Invoicing Section-Actual Rental only = Output 8 Amount charged Item Amount Invoicingsections, Actual Rental only Billed Period: Output 30 Billing startdate, end Item Quantity Invoicing     to date and number of section only    (   days days) Output 3 Number of days Item Quantity Invoicing,Actual authorized Rental Section only Sales Tax Output 3 Sales Tax ItemDescription Invoicing, Actual (  %) Rental section only Billed Period:Output 30 Billing start date, end Bill to End Date Invoicing     to dateand number of section only     (   days days) Billed Period: Output 30Billing start date, end Bill to Start Date Invoicing     to date andnumber of section only     (   days days) Federal ID: Output 12 FederalID Number Federal ID Only shown in Number Invoicing sections InvoiceDate: Output 10 Invoice Date Record Add Date Only used in the invoicesections Reference: Output 32 Reference Number Invoice Number Only inthe invoice sections Amount Output 8 Amount Received Total AmountInvoicing, Actual Received Received Rental sections only Total Charges:Output 8 Total Charges Total Invoicing, Actual Ticket Charges RentalSection only Total Due: Output 8 Total Due Total Invoicing, ActualAmount Due Rental sections only Handling For: Output 30 Handling forFirst Name + Adjuster's Name Last Name Authorized Output 30 AuthorizedStart Date Start Date + End Only in invoicing Period:     Date + Dayssections to     authorized-detail (   days) Date Output 8 MessageCreation Add Date N/A. Date Message to Output 50 Message Text NOTEBranch Location: Notebook Output 50 Message Text NOTE N/A. AuthorizedOutput 20 Car Class Name Vehicle Class Class: Current Class: Output 20Car Class Name Vehicle Class N/A. Claim Number: Output 11 Claim NumberInsurance Claim Number Claim No. Output 30 Claim Number Insurance ClaimNumber Daily Output 10 Daily Policy Rate and Dollars Per Day InvoicingRate/Max. Maximum Policy Covered + Max $ section only Dollars RateCovered Direct Bill Output 4 Direct Bill Percent Bill To % InvoicingPercent sections only Direct Bill Output 8 Direct Bill Percent Bill To %Invoicing sections Percent Actual Rental only Output 30 Rental LocationRental Location Branch Name Days/Rate Output 6 Rental Location RateNumber Of Days N/A. and number of days Authorized Days/Rate Output 6Rental Location Rate Vehicle Rate N/A. and number of days @ Output 7Rental Rate per day Rate Charged Invoicing section only Rental Period:Output 30 Rental Start Start Date + Invoicing     to End Date + sectionsonly     CALCULATED (   days) Rental Date Output 10 Rental Start DateStart Date Start Date Output 10 Start Date of rental Start Date InsuredName: Output 30 Insured's Name First Name + Last Name Output 30 RentalLocation Address Line + N/A. Address Address Line2 Output 25 RentalLocation City City N/A. Name Output 10 Rental Location Postal/ Zip CodeN/A. Zip Code Output 3 Rental Location State/ State N/A. Province CodeOutput 13 Rental Location Telephone N/A. Telephone Number Number Date ofLoss: Output 10 Date of Loss Date Of Loss Output 20 Renter City NameCity Output 10 Renter Postal/ Zip Code Zip Code Output 3 Renter State/State Province Code Output 30 Renter Street Address Line Address RenterEmail: Output 20 Renter's Email Day Phone Home Phone: Output 16 Renter'sHome Renters Night Phone Phone + Renters Night Phone Extension RenterOutput 30 Renter's Name First Name + N/A. Information: Last Name RenterName: Output 30 Renter's Name First Name + Last Name Owner's Output 4Renter's Vehicle Renter Vehicle Vehicle Year, Make and Year + RenterModel Make/Model Work Phone: Output 16 Renter's Work Phone Day Phone +Renters Day Phone Extension Repair Facility: Output 20 Body Shop NameRepair Facility Name Phone Output 16 Body Shop Phone Telephone Number:Number Number Output 20 Repair Facility City City Output 3 RepairFacility State State Output 7 Repair Facility Zip Zip Code Code = Output10 Amount charged CALCULATED Invoicing sections only Total Output 8Total authorized CALCULATED Invoicing authorized amount sections onlyIncludes Tax & Surcharge Renter Type Output 15 Claim Type claim typedescription Claims Office: Output 3 Office Id external organizationabbreviated name Vehicle Output 15 Loss Type loss type Conditiondescription Renter Email: Output 20 Renter's Email renter email

-   -   2.2.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.2.3.1 Previous            -   When clicked, the USER will be taken back to the use                case from where they came.        -   2.2.3.2 Printer Friendly Version            -   When clicked, the system will bring up a screen that                only shows the particular invoice for which you clicked                this button. The USER may print from this screen.        -   2.2.3.3 Top of page            -   When clicked, the USER will be taken to the top of the                current page.

2.3 Search Results

-   -   This screen will allow the USER To view the rental when closed.    -   2.3.1 Screen Layout—Search Results—see FIG. 130    -   2.3.2 Search Results

Screen Label Type Size Screen Field Name Data Field Name Screen SpecificRule Last Date Output 10 Authorization Date Status List Box 10 ContractStatus Status Code last date Input 5 Last Day LAST AUT DAY authorizedAuthorized adj. last name Input 15 Adjuster Last Name Last Name AdjusterOutput 20 Adjuster Name First Name + Name: Last Name Handling for: ListBox 15 Handling for First Name + Adjuster Name Last Name File TypeOutput 15 Status Status Description confirmation Input 52 ConfirmationTransmission number Number Code Claim Number Output 30 Claim NumberInsurance Claim Populated by the Number data matching the searchcriteria claim number Input 30 claim number Insurance Claim Number LossDate Output 10 Date of Loss Date Of Loss first name Input 15 Renter'sFirst Name First Name last name Input 15 Renter's Last Name Last NameRenter's Name Output 30 Renter's Name First Name + Returned data fromLast Name the search criteria Claims Office: List Box 5 Office IDexternal organization abbreviated name You requested Output 30 SearchCriteria NOT STORED This field will be a search for: populated by thecriteria used to search for a particular record. This field may be atLast Name, First Name, Claim Number, Confirmation Number, Adjuster LastName or Status. The data in this field

-   -   2.3.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.3.3.1 Search Again            -   When clicked, the system will re-search the database                after the USER has entered new or additional criteria.        -   2.3.3.2 Top of page            -   When clicked, the USER will be taken to the top of the                current page.        -   2.3.3.3 View Next 10>>>            -   When clicked, the system will display the next 10 items                that match the search criteria.

3. Application Operations 4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 Add Date

Entity ARM: ARMS/ 400 Diary Notes File Column Name NEADDT Label Name AddDate System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.2 Address Line

Entity ARM: Renter Location Master Column Name LOADL1 Label Name SystemName Data Type CHAR(30) Attribute Definition

-   -   4.1.3 Address Line

Entity ARM: Renter Detail Column Name RKADL1 Label Name Address LineSystem Name Data Type CHAR(30) Attribute Definition

-   -   4.1.4 Address Line2

Entity ARM: Renter Location Master Column Name LOADL2 Label Name AddressLine System Name Data Type CHAR(30) Attribute Definition

-   -   4.1.5 Bill To %

Entity ARM: Authorization(Claim Info) Column Name AZBTPC Label Name BillTo % System Name Data Type DECIMAL(3) Attribute Definition

-   -   4.1.6 Bill to End Date

Entity A4 Invoice Header Column Name IIBTDT Label Name Bill to End DateSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.7 Bill to Start Date

Entity A4 Invoice Header Column Name IISRDT Label Name Bill to StartDate System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.8 Branch

Entity ARM: Rental Location Master Column Name Branch Label Name Branch:System Name Data Type CHAR(2) Attribute Definition

-   -   4.1.9 City

Entity ARM: Rental Location Master Column Name LOCYNM Label Name CitySystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.10 City

Entity ARM: Renter Detail Column Name RKCYNM Label Name City System NameData Type CHAR(20) Attribute Definition

-   -   4.1.11 City

Entity ARM: Repair Detail Column Name RUCYNM Label Name City System NameData Type CHAR(20) Attribute Definition

-   -   4.1.12 claim type code

Entity AUTHORIZATION EXTENSION Column Name clm_typ_cde Label Name claimtype code: System Name CLMTYPCDE Data Type DEC(3, 0) AttributeDefinition The claim type code defines the different Authorization claimtypes. For example: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.13 claim type description

Entity CLAIM TYPE Column Name clm_typ_dsc Label Name claim typedescription: System Name CLMTYPDSC Data Type CHAR(40) AttributeDefinition The claim type description is a lexical definition of theclaim type code which defines the different Authorization claim types.For example: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.14 company identifier

Entity EXTERNAL ORGANIZATION Column Name cmpy_id Label Name companyidentifier: System Name CMPYID Data Type DEC(11, 0) Attribute DefinitionBusiness Party Identifier is a surrogate key assigned to each uniqueoccurrence of an Individual, External Organization, and InternalOrganization (Business Party).

-   -   4.1.15 Date of Loss

Entity ARM: Renter Detail Column Name RKLSDT Label Name Date Of LossSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.16 Day Phone

Entity ARM: Renter Detail Column Name RKDYPH Label Name Day Phone SystemName Data Type NUMERIC(10) Attribute Definition

-   -   4.1.17 Days authorized-detail

Entity ARM: ARMS/400 Diary Notes File Column Name NEAUDY Label Name Daysauthorized-detail System Name Data Type DECIMAL(3) Attribute Definition

-   -   4.1.18 Dollars Per Day Covered

Entity ARM: Authorization(Claim Info) Column Name AZ$PDY Label NameDollars Per Day Covered System Name Data Type DECIMAL(5, 2) AttributeDefinition

-   -   4.1.19 End Date

Entity ARM: Authorization(Claim Info) Column Name AZENDT Label Name EndDate System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.20 external organization identifier

Entity EXTERNAL ORGANIZATION Column Name e_o_id Label Name externalorganization identifier: System Name EOID Data Type DEC(11, 0) AttributeDefinition The external organization identifier is a surrogate keyassigned to each unique occurrence of an External Organization.Examples: body shops, vehicle manufacturers, insurance companies,leasing accounts, credit unions, dealerships, or government agencies.

-   -   4.1.21 Federal ID Number

Entity A4 Invoice Header Column Name IIFETX Label Name Federal ID NumberSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.22 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.23 First Name

Entity ARM: Insured Detail Column Name IRFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.24 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.25 Group

Entity ARM: Rental Location Master Column Name Group Label Name GroupNumber System Name Data Type CHAR(2) Attribute Definition

-   -   4.1.26 Insurance Claim Number

Entity ARM: Authorization(Claim Info) Column Name AZCLNO Label NameInsurance Claim Number System Name Data Type CHAR(20) AttributeDefinition

-   -   4.1.27 Invoice Number

Entity A4 Invoice Header Column Name I1INNO Label Name Invoice NumberSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.28 LAST AUT DAY

Entity A4 Cross Reference Column Name X4LADT Label Name LAST AUT DAYSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.29 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.30 Last Name

Entity ARM: Insured Detail Column Name IRLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.31 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.32 loss type code

Entity AUTHORIZATION EXTENSION Column Name loss_typ_cde Label Name losstype code: System Name LOSSTYPCDE Data Type DEC(3, 0) AttributeDefinition The loss type code defines the different loss categories whenan Insurance Company authorizes a Rental. For example: Theft, Drivable,Repairable, Non-drivable, Non-repairable, Totaled.

-   -   4.1.33 loss type description

Entity LOSS TYPE Column Name loss_typ_dsc Label Name loss typedescription: System Name LOSSTYPDSC Data Type CHAR(40) AttributeDefinition The loss type description is a lexical definition of the losstype code which defines the different loss categories when an InsuranceCompany authorizes a Rental. For example: Theft, Drivable, Repairable,Non-drivable, Non-repairable, Totaled.

-   -   4.1.34 Max $ Covered

Entity ARM: Authorization (Claim Info) Column Name AZ$MAX Label Name MAX$ Covered System Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.35 message ecars indicator

Entity AUTHORIZATION MESSAGE Column Name msg_ecars_ind Label Namemessage ecars indicator: System Name MSGECARIND Data Type CHAR(1)Attribute Definition The message ecars indicator indicates whether themessage is sent/received from the ecars system.

-   -   4.1.36 NOTE

Entity ARM: ARMS/400 Diary Notes File Column Name NENOTE Label Name NOTESystem Name Data Type CHAR(50) Attribute Definition

-   -   4.1.37 Number Of Days Authorized

Entity ARM: Authorization(Claim Info) Column Name AZAUDY Label NameNumber Of Days Authorized System Name Data Type DECIMAL(3) AttributeDefinition

-   -   4.1.38 Rate Charged

Entity ARM: Authorization(Claim Info) Column Name AZRTCH Label Name RateCharged System Name Data Type DECIMAL(5, 2) Attribute Definition

-   -   4.1.39 Record Add Date

Entity A4 Invoice Header Column Name I1ADDT Label Name Record Add DateSystem Name Data Type NUMBER(8) Attribute Definition

-   -   4.1.40 Rental Location

Entity ARM: Authorization(Claim Info) Column Name AZRNLC Label NameRental Location System Name Data Type CHAR(10) Attribute Definition

-   -   4.1.41 renter email

Entity RENTER EXTENSION Column Name rentr_eml Label Name renter email:System Name RENTREML Data Type CHAR(70) Attribute Definition The emailaddress of the renter.

-   -   4.1.42 Renter Make/Model

Entity ARM: Renter Detail Column Name RKVHMM Label Name RenterMake/Model System Name Data Type CHAR(15) Attribute Definition

-   -   4.1.43 Renter Vehicle Year

Entity ARM: Renter Detail Column Name RKVHYR Label Name Renter VehicleYear System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.44 Renters Day Phone Extension

Entity ARM: Renter Detail Column Name RKDYEX Label Name Renters DayPhone Extension System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.45 Renters Night Phone

Entity ARM: Renter Detail Column Name RKNTPH Label Name Renters NightPhone System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.46 Renters Night Phone Extension

Entity ARM: Renter Detail Column Name RKNTEX Label Name Renters nightPhone Extension System Name Data Type NUMERIC(4) Attribute Definition

-   -   4.1.47 Repair Facility Name

Entity ARM: Repair Detail Column Name RURFNM Label Name Repair FacilityName System Name Data Type CHAR(35) Attribute Definition

-   -   4.1.48 standard message description

Entity STANDARD MESSAGE Column Name std_msg_dsc Label Name standardmessage description: System Name STDMSGDSC Data Type CHAR(50) AttributeDefinition The standard message description if a lexical definition forstandard message code which defines a predefined message which isapplicable to specific activity type code. For example: “Authorizationconfirmed on & Date with Reservation Number & Resnumber”

-   -   4.1.49 Start Date

Entity ARM: Authorization(Claim Info) Column Name AZSTDT Label NameStart Date System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.50 State

Entity ARM: Rental Location Master Column Name LOSACD Label Name StateSystem Name Data Type CHAR(2) Attribute Definition

-   -   4.1.51 State

Entity ARM: Renter Detail Column Name RKSACD Label Name State SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.52 State

Entity ARM: Repair Detail Column Name RUSACD Label Name State SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.53 Status Description

Entity ARM: ARMS/400 Cross Reference Status Table File Column NameXUSTDS Label Name Status Description System Name Data Type CHAR(6)Attribute Definition

-   -   4.1.54 Telephone Number

Entity ARM: Rental Location Master Column Name LOPHNO Label NameTelephone Number System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.55 Telephone Number

Entity ARM: Repair Detail Column Name RUPHNO Label Name Telephone NumberSystem Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.56 Total Amount Due

Entity A4 Invoice Trailer Column Name 13BL$$ Label Name Total Amount DueSystem Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.57 Total Amount Received

Entity A4 Invoice Trailer Column Name 13RC$$ Label Name Total AmountReceived System Name Data Type DECIMAL(9,2) Attribute Definition

-   -   4.1.58 Total Ticket Charges

Entity A4 Invoice Trailer Column Name 13TO$$ Label Name Total TicketCharges System Name Data Type DECIMAL(9,2) Attribute Definition

-   -   4.1.59 Transmission Code

Entity ARM: ARMS/400 Diary Notes File Column Name NETRCD Label NameTransmission Code System Name Data Type Char(1) Attribute Definition

-   -   4.1.60 Vehicle Class

Entity ARM: Authorization(Claim Info) Column Name AZVHCS Label NameVehicle Class System Name Data Type CHAR(2) Attribute Definition

-   -   4.1.61 Vehicle Rate

Entity ARM: Authorization(Claim Info) Column Name AZVHRT Label NameVehicle Rate System Name Data Type DECIMAL(5,2) Attribute Definition

-   -   4.1.62 Zip Code

Entity ARM: Rental Location Master Column Name LOZPCD Label Name ZipCode System Name Data Type CHAR(9) Attribute Definition

-   -   4.1.63 Zip Code

Entity ARM: Rental Detail Column Name RKZPCD Label Name Zip Code SystemName Data Type CHAR(9) Attribute Definition

-   -   4.1.64 Zip Code

Entity ARM: Repair Detail Column Name RUZPCD Label Name Zip Code SystemName Data Type CHAR(9) Attribute Definition

Functional Design Specification Handle Unapproved Invoices Version1.1 1. Handle Unapproved Invoices Use Case 1.1 Brief Description

-   -   The Handle Unapproved Invoices use case describes how the        Adjuster would review invoices and approve them for payment. The        use case will then describe the processes the Adjuster will        follow in the case where the Adjuster is the one that is        actually paying the invoice.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:        -   ADJUSTER—The ADJUSTER will use this case to approve and            either pay unapproved invoices or send them on to a            PROCESSOR for payment.

1.3 Pre-Conditions

-   -   The ADJUSTER must be logged into the ARMS Web system.    -   The ADJUSTER'S office must be set up for individual approval of        invoices.    -   The ADJUSTER must be able to handle invoices.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps for an        ADJUSTER to approve and pay invoices.    -   1.4.1 Activity Diagram—see FIG. 131.    -   1.4.2 Basic Flow        -   1. The ADJUSTER will view the detail of the invoice.        -   2. If the ADJUSTER chooses to pay the invoice immediately,            execute subflow 1.4.2.3—Pay a Single Invoice. Otherwise            continue the Basic Flow.        -   3. The ADJUSTER will approve the invoice.        -   4. The system will mark the invoice approved.        -   5. If the ADJUSTER pays their invoices, then the invoice            will be added to their payment list. If a PROCESSOR pays            their invoices, then the invoice will be added to the            PROCESSOR'S payment list.        -   6. The system will update the ARMS Web database.        -   7. If this is the last or only invoice in the action items            list, then continue to step eight of the Basic Flow.            Otherwise, the use case ends.        -   8. The system will check to see if the ADJUSTER'S office is            set up for individual payment or bulk payment.            -   If the ADJUSTER'S office is set up for individual                payment execute subflow 1.4.2.1, Individual Pay.            -   If the ADJUSTER'S office is set up for bulk payment                execute subflow 1.4.2.2, Bulk Pay.        -   1.4.2.1 Individual Payment List            -   1. The system will display instructions for paying the                invoices individually and a summary list of all the                invoices just approved by the ADJUSTER.            -   2. For each invoice on the payment list, the ADJUSTER                may enter the associated check number.            -   3. The ADJUSTER will submit the payment list to the                system.            -   4. The system will mark the invoice paid.            -   5. The system will update the ARMS Web database.            -   6. This ends the use case.        -   1.4.2.2 Bulk Payment List            -   1. The system will display instructions for paying the                invoices in bulk and a summary list of all the invoices                just approved by the ADJUSTER.            -   2. The ADJUSTER may enter the check number of the check                that is paying all the invoices on the payment list.            -   3. The ADJUSTER will submit the payment list to the                system.            -   4. The system will mark the invoice paid.            -   5. The system will update the ARMS Web database.            -   6. This ends the use case.        -   1.4.2.3 Pay A single Invoice            -   1. The ADJUSTER may enter the check number for the                invoice being paid.            -   2. The system will mark the invoice paid.            -   3. The system will update the ARMS Web database.            -   4. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Selected Action Item is Payment List            -   At step one of the Basic Flow, if the action item being                worked is the “Payment List” action item, then the                ADJUSTER will be taken immediately to step one of                section 1.4.2.1 if they are set up for individual pay,                or step one of section 1.4.2.2 if they are set up for                bulk pay.        -   1.4.3.2 Reject an Invoice            -   At step one in the Basic Flow, the ADJUSTER may choose                to reject the invoice. The rejection process is executed                using extension point BI-03—Reject an Invoice.        -   1.4.3.3 View Customer File            -   At Individual Payment List or Bulk Payment List, the                ADJUSTER may choose to view detail information about the                rental. The view rental detail process is executed using                extension point MA-19—View Customer File.        -   1.4.3.4 Print a Single Invoice            -   At step one in the Basic Flow, the ADJUSTER may choose                to print the invoice. If they so choose, they may also                print the rental history. The system will display a                printer friendly screen and the ADJUSTER will choose to                print via their browser window. Upon printing, the                ADJUSTER will choose to return to the step one of the                Basic Flow by hitting the “back” button on the web                browser.        -   1.4.3.5 Print an Invoice List            -   At step one in section 1.4.2.1, Individual Pay, or                section 1.4.2.2, Bulk Pay, the ADJUSTER may choose to                print the invoice list of all invoices on the Payment                List. If they so choose, they may also print the rental                history for all invoices. The system will display a                printer friendly screen and the ADJUSTER will choose to                print via their browser window. Upon printing, the                ADJUSTER will choose to return to the step one of                section 1.4.2.1 if the ADJUSTER is set up for Individual                Pay, or section 1.4.2.2 if the ADJUSTER is set up for                Bulk Pay.        -   1.4.3.6 Skip Invoice            -   At step three in the Basic Flow, the ADJUSTER may choose                to skip the invoice in question and handle it at a later                time. The ADJUSTER will be taken to the next action item                on their action item list. The status of the invoice                should not be changed by the ARMS Web system.        -   1.4.3.7 Payment by PROCESSOR            -   If the ADJUSTER is only responsible for approving the                invoice, then, after step four in the Basic Flow, the                system will make the approved invoice an action item for                the PROCESSOR(S) responsible for paying the ADJUSTER'S                invoices. This ends the use case. Payment by PROCESSOR                is handled via Functional Specification BI-02—Pay                Approved Invoices.        -   1.4.3.8 Amount Being Approved Exceeds USER'S Authorization            Limits            -   When a USER attempts to approve an invoice for payment,                the system will check to see if the amount due on the                invoice is greater than the USER's authorization amount.                If the amount due is greater than the USER'S limit, the                system will not allow the approval and will request that                the USER transfer the invoice to another user with                authorization limits that are great enough to approve                the invoice.        -   1.4.3.9 Change Claim Number            -   At step one in the Basic Flow, if the status is                “rejected” and if the profile allows, the ADJUSTER may                choose to change the claim number associated with an                invoice. Once a claim number has been updated, the                ADJUSTER will continue with step four of the basic.

1.5 Post-Conditions

-   -   If the use case was successful and the ADJUSTER is responsible        for paying invoices, the approved invoices should be marked as        paid in the ARMS Web system.    -   If the use case was successful and the ADJUSTER is only        responsible for approving invoices, then the approved invoices        should be marked as adjuster approved in the ARMS Web system.

1.6 Special Requirements

-   -   The additional requirements of the business use case are        included here. These are requirements not covered by the flow as        they have been described in the sections above.    -   1.6.1 ARMS Web Routes Invoices        -   Before an ADJUSTER receives an invoice to be approved, the            ARMS Web system will look at the invoicing criteria for the            owning office and owning adjuster and make a determination            as to whether the invoice is auto approved or adjuster            approved. If an invoice is auto approved, the invoice will            always be assigned to a processor for payment without it            ever being sent to an adjuster for approval. The payment            method may be either bulk or individual payment.    -   1.6.2 Includes Tax and Surcharge Data Field        -   On the invoice next to the authorized amount, the field            “Includes Tax and Surcharge” will be displayed next to the            Authorized total if that total should include taxes and            surcharges. This will occur in two events. For an insured,            if the authorized amount is less than the policy daily            amount, the authorized total will include taxes and            surcharges up to the policy daily amount. For a claimant,            the authorized amount will always include taxes and            surcharges, without limit, until the rental is terminated by            the ADJUSTER.    -   1.6.3 Data Fields to Assist with Future Releases or Customer        Integration    -   It must be possible to capture the following information at some        point in the future because of either planned future releases or        customer integration.        -   Amount Being Paid on Each Invoice

1.7 Extension Points

-   -   An extension point indicates a link between this use case and        another use case. Extension points associated with the use case        are indicated below. Clicking on the extension point will open        the related use case.    -   1.7.1 BI-03 Reject an Invoice        -   The Reject an Invoice Functional Specification is used to            reject a specific invoice to Enterprise due to missing            required information or an incorrect amount on the bill.            Upon completion of the Reject an Invoice Functional            Specification, the ADJUSTER should be returned to step six            of the Basic Flow in the Handle Unapproved Invoices            Functional Specification. Any previously approved invoices            should still be approved in the system. The rejected invoice            should be marked as rejected by the system. The Handle            Unapproved Invoices Functional Specification will only allow            for one invoice to be rejected at a time.    -   1.7.2 MA-19—View Rental Detail        -   The View Rental Detail Functional Specification is used to            review the rental history in regards to a specific rental.            Upon completion of the View Rental Detail Functional            Specification, the ADJUSTER should be returned to step four            of the Basic Flow in the Handle Unapproved Invoices            Functional Specification. Any previously approved invoices            should still be approved in the system.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Invoicing—Individual Payment

-   -   This screen will allow the user to choose to view the invoice        selected in the action items list. They will choose to either        pay this invoice immediately (pay now), or choose to add it to a        payment list for payment later in conjunction with all their        other invoices. They may also choose to print the invoice from        this page. They may also optionally choose to print the rental        history. The user may choose to change the claim number. Finally        the user may choose to skip this invoice and leave it until        later for review.    -   2.11 Invoicing—Individual Payment—see FIG. 132

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleOutput 30 Rental Location's Address Line + Mailing Street Address Line2Address Output 15 Line Item Charge Item Description This line may repeatDescription multiple times depending on the number of taxes andsurcharges that apply. Output 15.2 Line Item Charge Item Amount LineItem Charge Qty * Description Line Item Charge Amount. This line mayrepeat multiple times depending on the number of taxes and surchargesthat apply. Claim No: Input 15 Claim Number Insurance Claim NumberInvoice Date: Output 10 Invoice Date (Ecar's Record Add Date TicketDate) Reference: Output 20 Invoice ID Invoice Number Rental Group ID +Rental Branch ID + ECARS Ticket Number Please include Output 20 InvoiceId Invoice Number Rental Group Id + this reference Rental Branch Id +number on ECARS Ticket your check Number Federal ID: Output 30Location's Federal Id. Federal ID Number Federal ID: Output 30Location's Federal ID Federal ID Number Amount Output 15.2 Amount ofrental Total Amount Received Charges received Received Total Due: Input15.2 Total Amount Due Total Amount Due from Ins. Company Total Charges:Output 15.2 Total Rental Ticket Total Ticket Charges Charges HandlingFor: Output 30 Handling for First Name + Last Adjuster's First name +Adjuster's Name Name Adjuster's last name. The name of the adjuster towhich the invoice is currently assigned. Output 150 Messages NOTE Thisfield will repeat multiple lines for all diary notes (messages) for thisreservation. to Output 10 Authorization End Date Termination Date toOutput 10 Authorization End Date Termination Date Direct Bill Output15.0 Authorized Bill Bill to % Percent percentage Direct Bill Output15.0 Authorized Bill Bill to % Percent percentage Authorized Output 10Authorized Start Date Start Date Period: Billed Period: Output 10Authorized Start Date Start Date Claim Number Input 15 Claim NumberInsurance Claim Will be pre-filled with Number the claim numbercurrently on the authorization. to Output 10 Close date of Rental EndDate Ticket Policy: Daily Output 15.2 Policy Daily Dollars Per DayRate-Max Maximum Amount + Covered Dollars: Policy Maximum Policy: DailyOutput 15.2 Policy Daily Max $ Covered Rate/Max Maximum Amount +Dollars: Policy Maximum Rental Period: Output 10 Start date of RentalStart Date Ticket Insured Name Output 30 Insured's Name First Name +Last Name For Output 30 Insured's name First Name + Last Name Output 30Rental Location's City + State + Zip Mailing City, State Code and ZipCode Output 30 Rental Location's Address Line + Mailing Street StressAddress Line2 Output 15 Rental Location's Telephone Number Phone NumberOutput 30 Rental Location's City mailing City, State, and Zip Output 30Rental Location's State Mailing City, State, and Zip Output 30 RentalLocation's Zip Code mailing City, State, and Zip Output 30 RentalLocation's Address Line + Mailing Street Address Line2 Address Output 15Rental Location's Telephone Number This field is repeated Phone Numberfor each invoice in the payment list. Renter Output 30 Renter's NameFirst Name + Last Name ( Output 5 Number of CALCULATED Authorized Days (Output 5 Number of CALCULATED authorized days ( Output 5 Number ofRental CALCULATED Days Total Due Output 15.2 Total Amount Due CALCULATEDTotal Charges − from Ins. Company Amount Received Number of Output 15.2Total Authorized CALCULATED Number of Authorized Amount before taxAuthorized Days * Dates + “@” + and surcharge Authorized Dailyauthorized Rate Daily Rate + “/day=” Total Output 15.2 Total authorizedCALCULATED (Number of authorized amount with Tax and authorized Days *includes Tax & surcharge Authorized Daily Surcharge Rate) + CalculatedTax and surcharge Number of Output 15.2 Total Ticket Rental CALCULATEDNumber of Rental Rental Days + Amount before tax Days * ECARS “@” +ECAR's and surcharge Ticket Daily Rate. Ticket Daily Rate + “/day=”Claim Type: Output 10 Claim Type claim type description Claims Office:Output 3 Office Id external organization The claims office idabbreviated name which the user is currently process work for. VehicleOutput 20 Loss Type loss type description Condition Rental Output 30Rental Location's accounting name Accounting Name Send Payment Output 30Rental Location's accounting name To: Accounting Name Check Number Input20 Check Number check number for your payment

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 PRINTER FRIENDLY PAGE            -   When clicked, the user will be taken to the “Printer                Friendly View” of the current invoice.        -   2.1.3.2 REJECT            -   When clicked, the user will be taken to the Reject                Invoice process.        -   2.1.3.3 PAY NOW            -   When clicked, the system will edit the current                information. If the edit passes, the invoice will be                marked as paid and the data files updated. If the                validation fails, the user will be returned to the                current screen with the errors highlighted.            -   2.1.3.3.1 The system will validate that the user has an                authorization limit high enough to approve the invoice.                If not, the system will generate an error and ask the                USER to transfer the invoice.        -   2.1.3.4 ADD TO PAYMENT LIST            -   When clicked, the system will edit the current                information for check number and claim number. If the                edit passes, the invoice will be marked as approved and                will be added to the ADJUSTER'S payment list and the                user will be returned to the Review List process.        -   2.1.3.5 SKIP>>            -   When clicked, the user will be advanced to the next                action item to be processed and the current invoice will                remain unchanged (un-approved).        -   2.1.3.6 Top of Page            -   When clicked, the user will be taken to the top of the                current invoice page.        -   2.1.3.7 Transfer File            -   When clicked, the system will present a list of users                that have authorization limits greater than the amount                due on the invoice. The USER may then choose one user                from this list to which they may transfer the file.        -   2.1.3.8 Policy Information            -   Policy Information will only be shown under the                Authorized Section if the claim type is NOT claimant.

2.2 Invoicing—Approval

-   -   This screen will allow the user to choose to view the invoice        selected in the action items list. They may choose to approve        the invoice payment. This will add the invoice to the        PROCESSOR(S) that are responsible for paying the ADJUSTER'S        invoices. The user may also choose to skip this invoice and        leave it until later for review. They may choose to print the        invoice from this page. They may also optionally choose to print        the rental history. Finally, the user may choose to change the        claim number.    -   2.2.1 Screen Layout—invoicing Approval.shtml—see FIG. 133    -   2.2.2 Invoice Approval

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleOutput 152 Line item Charge Item Amount Line Item Charge Qty * AmountLine Item Charge Amount. This line may repeat multiple times dependingon the number of taxes and surcharges that apply. Output 15 Line ItemCharge Item Description This line may repeat Description multiple timesdepending on the number of taxes and surcharges that apply. Claim No:Output 15 Claim Number Insurance Claim Number Claim Number 15 ClaimNumber Insurance Claim Will be pre-filled with Number claim numbercurrently on authorization. To Output 10 Close Date of billing Bill toEnd Date of Rental Ticket Invoice Date: Output 10 Invoice Date (ECARsRecord Add Date Ticket Date) Reference Output 20 Invoice Id InvoiceNumber Rental Group Id + Rental Branch Id + ECARS Ticket Number FederalID: Output 30 Location's Federal Id. Federal ID Number Billed PeriodOutput 10 Start date of billing of Bill to Start Date Rental TicketAmount Output 15.2 Amount of Rental Total Amount Received: received.Received Total Due Output 15.2 Total amount due Total Amount Due fromIns. Company Total Charges: Output 15.2 Total Rental Ticket Total TicketCharges Charges Handling For: Output 30 Handling for First Name + LastAdjuster's First name + Adjuster's Name Name Adjuster's last name. Thename of the adjuster to which the invoice is currently assigned. Output50 Messages NOTE This field will repeat multiple lines for all diarynotes (messages) for a reservation To Output 10 Authorization End DateTermination Date Direct Bill Output 15.0 Authorized Bill Bill To %Percent: percentage Direct Bill Output 15.0 Authorized Bill Bill To %Percent percentage Authorized Output 10 Authorized Start Date Start DatePeriod: To Output 10 Close Date of Rental End Date Ticket Policy: DailyOutput 15.2 Policy Daily Dollars Per Day Rate/Max Maximum Amount +Covered Dollars Policy Maximum Policy: Daily Output 15.2 Policy DailyMax $ Covered Rate/Max Maximum Amount + Dollars Policy Maximum RentalPeriod: Output 10 Start date of Rental Start Date Ticket Insured Name:Output 30 Insured's name First Name + Last Name For: Output 30 Insured'sName First Name + Last Renter's Last Name + Name Renter's First NameOutput 30 Rental Location's City + State + Zip Mailing City + MailingMailing City, State Code State + Mailing Zip and Zip Code Output 30Rental Location's Address Line + Mailing Street Address Line2 AddressOutput 15 Rental Location's Telephone Number Phone Number Date of loss:Output 20 Date of loss Date Of Loss Renter Output 30 Renter's name FirstName + Last Renter's Last Name + Name Renter's First Name ( Output 5Number of CALCULATED Total number of Authorized Days authorized rentaldays ( Output 5 Number of Billed CALCULATED Days ( Output 5 Number ofRental CALCULATED Total number of Days authorized Rental Days Total Due:Output 15.2 Total Amount Due CALCULATED Total Charges − from Ins.Company Amount Received Number of Output 15.2 Total authorizedCALCULATED Number of Authorized amount before tax Authorized Days *Days + “@” + and surcharge Authorized Daily Authorized Rate Daily Rate +“/day=” Total Output 15.2 Total Authorized CALCULATED (Number ofauthorized Amount with tax and authorized Days * includes Tax &surcharge Authorized Daily Surcharge Rate) + (Calculated Tax andsurcharge) Number of Output 15.2 Total Ticket Rental CALCULATED Numberof Rental Rental Days + Amount before tax Days * ECARS “@” + ECAR's andsurcharge Ticket Daily Rate Ticket Daily Rate + “/day=” Claim Type:Output 10 Claim Type claim type Claimant, Insured, description etc.Claims Office: Output 3 Office Id external organization The claimsoffice id abbreviated name which the user is currently process work for.Rental Output 30 Rental Location's accounting name Accounting Name

-   -   2.2.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.2.3.1 PRINTER FRIENDLY PAGE            -   When clicked, the user will be taken to the “Printer                Friendly View” of the current invoice.        -   2.2.3.2 REJECT            -   When clicked, the user will be taken to the Reject                Invoice process.        -   2.2.3.3 APPROVE FOR PAYMENT            -   When clicked, the currently displayed invoice status                will be marked as approved and the user will be taken to                the next Action Items.                -   The system will validate that the user has an                    authorization limit high enough to approve the                    invoice. If not, the system will generate an error                    and ask the USER to transfer the invoice.                -   Another adjuster has not already approved the                    invoice.        -   2.2.3.4 SKIP>>            -   When clicked, the user will be advanced to the next                selected action item to be processed and the current                invoice will remain unchanged (un-approved).        -   2.2.3.5 Top of Page            -   When clicked, the user will be taken to the top of the                current invoice page.        -   2.2.3.6 Transfer File            -   When clicked, the system will present a list of users                that have authorization limits greater than the amount                due on the invoice. The USER may then choose one user                from this list to which they may transfer the file.        -   2.2.3.7 Policy Information            -   Policy Information will only be shown under the                Authorized Section if the claim type is NOT claimant.

2.3 Individual Payment List

-   -   This screen provides the user with information on what the        system expects them to do, and requests a check number that will        be used to pay each invoice. The user may also choose to print        the invoices, and optionally print the rental history in        addition to the invoices. The user may choose not to process the        payment list at this time, in which case the payment list will        be added to the user's action items list.    -   2.3.1 Screen Layout—invoicingPymtList.shtml—see FIG. 134    -   2.3.2 Individual Payment List

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleClaim Number Input 15 Claim Number Insurance Claim Will be pre-filledwith Number claim number currently on authorization. This field isrepeated for each invoice in the payment list. This field is repeatedfor each invoice in the payment list. Invoice Date Output 10 InvoiceDate Record Add Date This field is repeated (ECARS Ticket Date) for eachinvoice in the payment list. Invoice: Output 20 Invoice Id InvoiceNumber Rental Group Id + Rental Branch Id + ECARS Ticket Number Thisfield is repeated for each invoice in the payment list. Please includeOutput 20 Invoice ID Invoice Number Rental Group ID + this referenceRental Branch ID + number on ECARS Ticket your check: number. This fieldis repeated for each invoice in the payment list. Federal ID Output 30Location's Federal ID Federal ID Number This field is repeated for eachinvoice in the payment list. Total Amount: Output 15.2 Total amount dueTotal Amount Due Total Charges − from Ins. Company Amount Received Thisfield is repeated for each invoice in the payment list. Handling For:Output 30 Handling for First Name + Last Adjuster's First name +Adjuster's Name Name Adjuster's last name. The name of the adjuster towhich the invoice is currently assigned. Output 30 Insured's Name FirstName + Last This field is repeated Name for each invoice in the paymentlist. Output 30 Rental Location's Address Line + This field is repeatedMailing Street Address Line2 for each invoice in Address the paymentlist. Output 12 Rental Location Telephone Number This field is repeatedTelephone Number for each invoice in the payment list. Output 30 RentalLocation's City + State + Zip This field is repeated Mailing City, StateCode for each invoice in and Zip Code the payment list. Output 30 RentalLocation's City + State + Zip This field is repeated Mailing City StateCode for each invoice in and Zip the payment list. Output 30 RentalLocation's Address Line + This field is repeated Mailing Street AddressLine2 for each invoice in Address the payment list. Date of loss Output10 Date of loss Date Of Loss This field is repeated for each invoice inthe payment list. Invoice Output 5 Invoice List Number CALCULATED Thisfield is repeated for each invoice in the payment list. Claim typeOutput 10 Claim Type claim type This field is repeated description foreach invoice in the payment list. Claims Office: Output 3 Office Idexternal organization This claims office id abbreviated name which theuser is currently process work for list. Vehicle Output 10 Loss Typeloss type description This field is repeated Condition for each invoicein the payment list. Remit to: Output 30 Rental Location's accountingname This field is repeated Accounting Name for each invoice in thepayment list. Rental: Output 30 Rental Location's accounting name Thisfield is repeated Accounting Name for each invoice in the payment list.Send Payment Output 30 Rental Location's accounting name This field isrepeated to: Accounting Name for each invoice in the payment list. Enterthe Input 20 Check Number check number This field is repeated checknumber for each invoice in of your the payment list. payment here:

-   -   2.3.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.3.3.1 PRINTER FRIENDLY PAGE            -   When clicked, the user will be taken to the “Printer                Friendly View” of the current invoice.        -   2.3.3.2 CONFIRM PAYMENT            -   When clicked, system will mark the reservation as paid                and update the database. The update will be passed to                the Arms system.        -   2.3.3.3 PAY LATER            -   When clicked, the user will be returned to view list and                the requests will remain unchanged.        -   2.2.3.4 Top of Page            -   When clicked, the user will be taken to the top of the                current invoice page.

2.4 Bulk Payment List

-   -   This screen provides the user with information on what the        system expects them to do, and requests a check number that will        be used to pay each invoice. The user may also choose to print        the invoices, and optionally print the rental history in        addition to the invoices. The user may choose not to process the        payment list at this time, in which case the payment list will        be added to the user's action items list.    -   2.4.1 Screen Layout—Bulk Payment List—see FIG. 135    -   2.4.2 Bulk Payment List

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleClaim Number Input 15 Claim Number Insurance Claim Will be pre-filledwith Number claim number currently on authorization. This field isrepeated for each invoice in the payment list. Invoice Date Output 10Invoice Date Record Add Date This field is repeated (ECARS Ticket Date)for each invoice in the payment list. Please include Output 20 InvoiceID Invoice Number Rental Group Id + this reference Rental Branch Id +number on ECARS Ticket your check: Number. This field is repeated foreach invoice in the payment list. Invoice: Output 20 Invoice Id InvoiceNumber Rental Group ID + Rental Branch ID + ECARS Ticket number. Thisfield is repeated for each invoice in the payment list. Federal IDOutput 30 Location's Federal ID Federal ID Number This field is repeatedfor each invoice in the payment list. Total Amount: Output 15.2 Totalamount due Total Amount Due Total Charges − from Ins. Company AmountReceived. This field is repeated for each invoice in the payment list.Handling For: Output 30 Handling for First Name + Last Adjuster's Firstname + Adjuster's Name Name Adjuster's last name. The name of theadjuster to which the invoice is currently assigned. Output 30 Insured'sName First Name + Last This field is repeated Name for each invoice inthe payment list. Output 30 Rental Location's Address Line + This fieldis repeated Mailing Street Address Line2 for each invoice in Address thepayment list. Output 12 Rental Location Telephone Number This field isrepeated Telephone Number for each invoice in the payment list. Output30 Rental Location's City + State + Zip This field is repeated MailingCity, State Code for each invoice in and Zip Code the payment list.Output 30 Rental Location's City + State + Zip This field is repeatedMailing City State Code for each invoice in and Zip the payment list.Output 30 Rental Location's Address Line + This field is repeatedMailing Street Address Line2 for each invoice in Address the paymentlist. Date of loss Output 10 Date of loss Date Of Loss This field isrepeated for each invoice in the payment list. Invoice Output 5 InvoiceList Number CALCULATED This field is repeated for each invoice in thepayment list. Count Claim type Output 10 Claim Type claim type Thisfield is repeated description for each invoice in the payment list.Claims Office: Output 3 Office Id external organization The claimsoffice id abbreviated name which the user is currently process work for.Vehicle Output 10 Loss Type loss type description This field is repeatedCondition for each invoice in the payment list. Remit to: Output 30Rental Location's accounting name This field is repeated Accounting Namefor each invoice in the payment list. Send Payment Output 30 RentalLocation's accounting name This field is repeated to: Accounting Namefor each invoice in the payment list. Rental: Output 30 RentalLocation's accounting name This field is repeated Accounting Name foreach invoice in the payment list.

-   -   2.4.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other activity.        -   2.4.3.1 PRINTER FRIENDLY PAGE            -   When clicked, the user will be taken to the “Printer                Friendly View” of the current invoices.        -   2.4.3.2 CONFIRM PAYMENT            -   When clicked, the system will mark the reservation as                paid and update the database. The update will be passed                to the Arms system. The user will then be returned to                the next action item or the Action Item screen if no                more action items exist.        -   2.4.3.3 PAY LATER            -   When clicked, the user will be returned to Action Items                and the request will remain unchanged.        -   2.4.3.4 Top of Page            -   When clicked, the user will be taken to the top of the                payment list.

3. Application Operations

-   -   This section will detail all the application operations that are        part of this Functional Specification Document.

3.1 Get Unapproved Invoices (Adjuster Id)

-   -   The build unapproved invoice list operation finds all the        invoices, that need approval, for the specified adjuster.

3.2 Approve Invoice (Invoice Number)

-   -   The approve invoice operation marks the specified invoice as        approved. This invoice is now ready to be paid.

3.3 Get Approved Invoices (Adjuster Id)

-   -   The build approved invoice list operation finds all the approved        invoices for the specified adjuster.

3.4 Get Invoice Detail (Invoice Number)

-   -   The build invoice detail operation gets the relevant invoice        information for the specified invoice number.

3.5 Pay Invoice (Invoice Number, Check Number)

-   -   The pay invoice operation records the check number specified by        the adjuster against the specified invoice and marks the invoice        as paid.

4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 accounting name

Entity OFFDRB OFFICE DIRECTORY BRANCH MASTER Column Name acctg_nam LabelName Accounting Name System Name Data Type VARCHAR(8) AttributeDefinition

-   -   4.1.2 action item assigned date

Entity ACTION ITEM Column Name actn_item_assn_dte Label Name action itemassigned date: System Name AITMASGNDT Data Type DATE AttributeDefinition The action item assigned date is the date the action item wasestablished and assigned to an administrator or adjustor.

-   -   4.1.3 action item complete date

Entity ACTION ITEM Column Name actn_item_cmpl_dte Label Name action itemcomplete date: System Name AITMCMPLDT Data Type DATE AttributeDefinition The action item complete date is the date the action item wascompleted by an administrator or adjustor.

-   -   4.1.4 action item effective date

Entity ACTION ITEM Column Name actn_item_eff_dte Label Name action itemeffective date: System Name AITMEFFDT Data Type DATE AttributeDefinition The action item effective date is the date the action itemwill become effective.

-   -   4.1.5 action item status code

Entity ACTION ITEM Column Name actn_item_stat_cde Label Name action itemstatus code: System Name Data Type CHAR(6) Attribute Definition Theaction item status code defines the status of this action item. Forexample:

-   -   4.1.6 action item type code

Entity ACTION ITEM Column Name actn_item_typ_cde Label Name action itemtype code: System Name Data Type DEC(3,0) Attribute Definition Theaction item type code defines specific tasks/action items associatedwith the Rental Authorization/Reservation activities accomplished byadjustors and administrators when contracting an insured with areplacement vehicle. For example: Closing an Of

-   -   4.1.7 action item type description

Entity ACTION ITEM TYPE Column Name actn_item_typ_dsc Label Name actionitem type description: System Name Data Type CHAR(40) AttributeDefinition The action item type description is a lexical definition ofan action item type code which defines specific tasks/action itemsassociated with the Rental Authorization/Reservation activitiesaccomplished by adjustors and administrators when contracting an

-   -   4.1.8 action related adjustor code

Entity ACTION ITEM Column Name actn_rel_adjr_cde Label Name AdjustorCode System Name ARADJRCDE Data Type CHAR(10) Attribute Definition Theaction related adjustor code is the adjustor code of the adjustor/userwhich requires completion of some action item work activity such as anoffice closing and adjustors/users who need to be moved to anotheroffice.

-   -   4.1.9 action related company identifier

Entity ACTION ITEM Column Name actn_rel_cmpy_id Label Name ARMS ProfileID System Name ARCMPYID Data Type CHAR(5) Attribute Definition Theaction related company identifier is the company identifier of theadjustor/user which requires completion of some action item workactivity such as an office closing and adjustors/users who need to bemoved to another office.

-   -   4.1.10 Address Line

Entity ARM: Rental Location Master Column Name LOADL1 Label Name SystemName Data Type CHAR(30) Attribute Definition

-   -   4.1.11 Address Line2

Entity ARM: Rental Location Master Column Name LOADL2 Label Name AddressLine System Name Data Type CHAR(30) Attribute Definition

-   -   4.1.12 Adjustor Code

Entity ARM: Adjustor Master Column Name ALAACD Label Name Adjustor CodeSystem Name Data Type CHAR(10) Attribute Definition

-   -   4.1.13 ARMS Profile ID

Entity ACTION ITEM Column Name ALCUID Label Name ARMS Profile ID SystemName Data Type CHAR(5) Attribute Definition The ARMS Profile ID is thecompany identifier used to uniquely define an authorization.

-   -   4.1.14 ARMS Profile ID

Entity ARM: Adjustor Master Column Name ALCUID Label Name ARMS ProfileID System Name Data Type CHAR(5) Attribute Definition

-   -   4.1.15 assigned to adjustor code

Entity ACTION ITEM Column Name assgn_to_adjr_cde Label Name AdjustorCode System Name AADJRCDE Data Type CHAR(10) Attribute Definition Theassigned to adjustor code is the adjustor code of the administrator oradjustor's who is assigned the action item.

-   -   4.1.16 assigned to company identifier

Entity ACTION ITEM Column Name assgn_to_cmpy_id Label Name ARMS ProfileID System Name ACMPYID Data Type CHAR(5) Attribute Definition Theassigned to company identifier is the company identifier of theadministrator or adjustor's who is assigned the action item.

-   -   4.1.17 Bill To %

Entity ARM: Authorization(Claim Info) Column Name AZBTPC Label Name BillTo % System Name Data Type DECIMAL(3) Attribute Definition

-   -   4.1.18 Bill to End Date

Entity A4 Invoice Header Column Name IIBTDT Label Name Bill to End DateSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.19 Bill to Start Date

Entity A4 Invoice Header Column Name IISRDT Label Name Bill to StartDate System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.20 check number

Entity RENTAL INVOICE PAYMENT Column Name chk_nbr Label Name checknumber: System Name CHKNBR Data Type DEC(11.0) Attribute Definition

-   -   4.1.21 City

Entity ARM: Rental Location Master Column Name LOCYNM Label Name CitySystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.22 claim type description

Entity CLAIM TYPE Column Name clm_typ_dsc Label Name claim typedescription: System Name CLMTYPDSC Data Type CHAR(40) AttributeDefinition The claim type description is a lexical defini- tion of theclaim type code which defines the different Authorization claim types.For ex- ample: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.23 company identifier

Entity EXTERNAL ORGANIZATION Column Name cmpy_id Label Name companyidentifier: System Name CMPYID Data Type DEC(11.0) Attribute DefinitionBusiness Party Identifier is a surrogate key assigned to each uniqueoccurrence of an Individual, External Organization, and InternalOrganization (Business Party)

-   -   4.1.24 company structure level code

Entity ACTION ITEM Column Name cmpy_strct_lvl_cde Label Name companystructure level code: System Name CMPYSLVLCD Data Type DEC(3.0)Attribute Definition The external organization structure level codeidentifies the kind or type of internal organi- zations of the externalorganizations which Enterprise Rent-A-Car does business with. Such as:Corporation, Branch Claims Office, Region, Area, Subregion, etc.

-   -   4.1.25 Customer Transaction ID

Entity ACTION ITEM Column Name AZCUTI Label Name Customer Transaction IDSystem Name Data Type CHAR(20) Attribute Definition The CustomerTransaction ID is the authorization transaction identifier which alongwith a company identifier uniquely define an authorization.

-   -   4.1.26 Date Of Loss

Entity ARM: Renter Detail Column Name RKLSDT Label Name Date of LossSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.27 Dollars Per Day Covered

Entity ARM: Authorization(Claim Info) Column Name AZ$PDY Label NameDollars Per Day Covered System Name Data Type DECIMAL(5.2) AttributeDefinition

-   -   4.1.28 End Date

Entity ARM: Authorization(Claim Info) Column Name AZENDT Label Name EndDate System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.29 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute Definition External Organization Abbreviated Name isa shortened text based label associated with an organization outside ofEnterprise. This name is sometimes used for accounting purposes.

-   -   4.1.30 external organization identifier

Entity ALTERNATE ORGANIZATION Column Name e_o_id Label Name externalorganization identifier: System Name EOID Data Type DEC(11.0) AttributeDefinition Business Party Identifier is a surrogate key assigned to eachunique occurrence of an Individual, External Organization, and InternalOrganization (Business Party).

-   -   4.1.31 Federal ID Number

Entity A4 Invoice Header Column Name IIFETX Label Name Federal ID NumberSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.32 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.33 First Name

Entity ARM: Insured Detail Column Name IRFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.34 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.35 handled by adjustor code

Entity ACTION ITEM Column Name handl_by_adjr_cde Label Name AdjustorCode System Name HNDADJRCDE Data Type CHAR(10) Attribute Definition Thehandled by adjustor code is the adjustor code of the administrator oradjustor's who is handling the action item.

-   -   4.1.36 handled by company identifier

Entity ACTION ITEM Column Name handl_by_cmpy_id Label Name ARMS ProfileID System Name HNDCMPYID Data Type CHAR(5) Attribute Definition Thehandled by company identifier is the company identifier of theadministrator or adjustor's who is handling the action item.

-   -   4.1.37 handling for adjustor code

Entity AUTHORIZATION ACTIVITY LOG Column Name handl_for_adtr_cde LabelName handling for adjustor code: System Name HNDADJRCDE Data TypeCHAR(10) Attribute Definition The handling for adjustor coder is theadjustor code of an adjustor/user who is handling authorizationactivities for another adjustor/user in the ARMS Web application.

-   -   4.1.38 handling for company identifier

Entity AUTHORIZATION ACTIVITY LOG Column Name handl_for_cmpy_id LabelName handling for company identifier: System Name HNDCMPYID Data TypeCHAR(5) Attribute Definition The handling for company identifier is thecompany identifier used to uniquely identify an adjustor/user who ishandling authorization activities for another adjustor/user in the ARMSWeb application.

-   -   4.1.39 Insurance Claim Number

Entity A4 Invoice Header Column Name IICLNO Label Name Insurance ClaimNumber System Name Data Type CHAR(20) Attribute Definition

-   -   4.1.40 Insurance Claim Number

Entity ARM: Authorization(Claim Info) Column Name AZCLNO Label NameInsurance Claim Number System Name Data Type CHAR(20) AttributeDefinition

-   -   4.1.41 Invoice Number

Entity A4 Invoice Header Column Name IIINNO Label Name Invoice NumberSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.42 Item Amount

Entity A4 Invoice Detail Column Name 12IT$$ Label Name Item AmountSystem Name Data Type DECIMAL(7.2) Attribute Definition

-   -   4.1.43 Item Description

Entity A4 Invoice Detail Column Name I2ITDS Label Name Item DescriptionSystem Name Data Type CHAR(30) Attribute Definition

-   -   4.1.44 Item Quantity

Entity A4 Invoice Detail Column Name I2ITQY Label Name Item QuantitySystem Name Data Type DECIMAL(5) Attribute Definition

-   -   4.1.45 Item Rate

Entity A4 Invoice Detail Column Name I2ITRT Label Name Item Rate SystemName Data Type DECIMAL(7.2) Attribute Definition

-   -   4.1.46 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.47 Last Name

Entity ARM: Insured Detail Column Name IRLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.48 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.49 loss type description

Entity LOSS TYPE Column Name loss_typ_dsc Label Name loss typedescription: System Name LOSSTYPDSC Data Type CHAR(40) AttributeDefinition The loss type description is a lexical definition of the losstype code which defines the different loss categories when an InsuranceCompany authorizes a Rental. For example: Theft, Drivable, Repairable,Non-drivable, Non-repairable, Totaled.

-   -   4.1.50 Max $ Covered

Entity ARM: Authorization(Claim Info) Column Name AZ$MAX Label Name Max$ Covered System Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.51 NOTE

Entity ARM: ARMS/400 Diary Notes File Column Name NENOTE Label Name NOTESystem Name Data Type CHAR(50) Attribute Definition

-   -   4.1.52 Number Of Days Authorized

Entity ARM: Authorization(Claim Info) Column Name AZAUDY Label NameNumber Of Days Authorized System Name Data Type DECIMAL(3) AttributeDefinition

-   -   4.1.53 Record Add Date

Entity A4 Invoice Header Column Name IIADDT Label Name Record Add DateSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.54 related office identifier

Entity ACTION ITEM Column Name rel_ofc_id Label Name related officeidentifier: System Name RELOFCID Data Type DEC(11, 0) AttributeDefinition The related office identifier is the identifier of the officeresponsible for the action item.

-   -   4.1.55 Remittance Reference #

Entity A4 Remit Reference No. Column Name Q5RMNO Label Name RemittanceReference # System Name Data Type NUMERIC(6) Attribute Definition

-   -   4.1.56 Request Type

Entity ACTION ITEM TYPE Column Name XURSTP Label Name Request TypeSystem Name XURSTP Data Type CHAR(1) Attribute Definition The requesttype is a code from the ARMS system which identifies whether adjustoraction is necessary for an authorization and what type of action.

-   -   4.1.57 Start Date

Entity ARM: Authorization(Claim Info) Column Name AZSTDT Label NameStart Date System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.58 State

Entity ARM: Rental Location Master Column Name LOSACD Label Name StateSystem Name Data Type CHAR(2) Attribute Definition

-   -   4.1.59 Status Code

Entity ACTION ITEM TYPE Column Name XUSTCD Label Name Status Code SystemName XUSTCD Data Type CHAR(1) Attribute Definition The status code is acode from the ARMS system which identifies whether an authorization is areservation, a ticket, unauthorized, invoiced, paid, etc.

-   -   4.1.60 Telephone Number

Entity ARM: Rental Location Master Column Name LOPHNO Label NameTelephone Number System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.61 Total Amount Due

Entity A4 Invoice Trailer Column Name 13BL$$ Label Name Total Amount DueSystem Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.62 Total Amount Received

Entity A4 Invoice Trailer Column Name 13RC$$ Label Name Total AmountReceived System Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.63 Total Billed to Others

Entity A4 Invoice Trailer Column Name 13OT$$ Label Name Total Billed toOthers System Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.64 Total Ticket Charges

Entity A4 Invoice Trailer Column Name 13TO$$ Label Name Total TicketCharges System Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.65 Vehicle Rate

Entity ARM: Authorization(Claim Info) Column Name AZVHRT Label NameVehicle Rate System Name Data Type DECIMAL(5, 2) Attribute Definition

-   -   4.1.66 Zip Code

Entity ARM: Rental Location Master Column Name LOZPCD Label Name ZipCode System Name Data Type CHAR(9) Attribute Definition

5. Questions and Answers

-   -   Issue Number: 256    -   Question: The calculation for authorized limit when displaying        the invoice detail does not take bill to percent into account        when all the following conditions are true:        -   Policy Maximum=0        -   Policy Daily>0        -   Vehicle Rate>0        -   Vehicle Rate<Policy Daily    -   or all the following conditions are true:        -   Policy Maximum>0        -   Policy Daily=0        -   Vehicle Rate>0    -   In all other cases, the amount is multiplied by the bill to        percent to get the authorized limit. Is this calculation        correct?    -   Status: Pending    -   Resolution: 3-14-00, D S E—Need to follow up with author to get        a further understanding of question.    -   3-23-00, Issue Mtg., Will get addressed in current state and        fix.    -   Issue Number: 257    -   Question: This is a presentation issue. The adjuster name on the        invoice detail screen will not show up in certain cases. This        code is in the *INZSR sub routine and needs some investigation        of scenarios to determine the exact flaw.    -   Status: Closed—Resolved    -   Resolution: 3-14-00, D S E—Need to follow up with author to get        a further understanding of question.

Functional Design Specification Pay Approved Invoices (Processor Pay)Version 1.0 1. Pay Approved Invoices Use Case 1.1 Brief Description

-   -   The Pay Approved Invoices use case describes how the PROCESSOR        would review and pay invoices in the ARMS Web system.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:        -   PROCESSOR—The PROCESSOR will use this use case to pay            approved invoices.

1.3 Pre-Conditions

-   -   The PROCESSOR must be logged into the ARMS Web system.    -   The PROCESSOR'S office must be set up to handle processor        payment of invoices.    -   The PROCESSOR must be authorized to handle invoices.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps for a        PROCESSOR to review and pay invoices.    -   1.4.1 Activity Diagram—see FIG. 136    -   1.4.2 Basic Flow        -   1. The PROCESSOR will view their payment list.        -   2. The system will check to see if the PROCESSOR'S office is            set up for individual payment or bulk payment.            -   If the PROCESSOR'S office is set up for individual                payment execute subflow 1.4.2.1, Individual Pay.            -   If the PROCESSOR'S office is set up for bulk payment                execute subflow 1.4.2.2, Bulk Pay.        -   1.4.2.1 Individual Pay            -   1. The system will display instructions for paying the                invoices individually and a summary list of all the                invoices on the PROCESSOR'S payment list.            -   2. For each invoice on the payment list, the PROCESSOR                may enter the associated check number.            -   3. The PROCESSOR will submit the invoices to the system.            -   4. The system will mark the invoices paid.            -   5. The system will update the ARMS Web database.            -   6. This ends the use case.        -   1.4.2.2 Bulk Pay            -   1. The system will display instructions for paying the                invoices in bulk and a summary list of all the invoices                on the PROCESSOR'S payment list.            -   2. The ADJUSTER may enter the check number of the check                that is paying all the invoices on the payment list.            -   3. The PROCESSOR will submit the invoices to the system.            -   4. The system will mark the invoices paid.                5. The system will update the ARMS Web database.                6. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 View Customer File            -   At step one of Section 1.4.2.1, Individual Pay, or                Section 1.4.2.2, Bulk Pay, the PROCESSOR may choose to                view detail information about the rental. The view                rental detail process is executed using extension point                MA-19—View Customer File.        -   1.4.3.2 Return an Invoice    -   At step one of Section 1.4.2.1, Individual Pay or Section        1.4.2.2, Bulk Pay the PROCESSOR may choose to return any invoice        to the ADJUSTER. The PROCESSOR may enter a message to explain        why they returned the invoice. The returned invoice should be        given a status of returned invoice. The invoice will then become        an action item for the owning ADJUSTER to review and correct.        -   1.4.3.3 Print an Invoice List    -   At step one in section 1.4.2.1, Individual Pay, or section        1.4.2.2, Bulk Pay, the PROCESSOR may choose to print the invoice        list of all invoices on the Payment List. If they so choose,        they may also print the rental history for all invoices. The        system will display a printer friendly screen and the PROCESSOR        will choose to print via their browser window. Upon printing,        the PROCESSOR will return to the step one of section 1.4.2.1 if        the PROCESSOR is set up for Individual Pay, or section 1.4.2.2        if the PROCESSOR is set up for Bulk Pay.

1.5 Post-Conditions

-   -   If the use case was successful the accepted invoices should be        marked as paid in the ARMS Web system.    -   If the use case was unsuccessful, the system state is unchanged.

1.6 Special Requirements

-   -   The additional requirements of the business use case are        included here. These are requirements not covered by the flow as        they have been described in the sections above.    -   1.6.1 ARMS Web Routes Invoices        -   Before an ADJUSTER receives an invoice to be approved, the            ARMS Web system will look at the invoicing criteria for the            owning office and owning adjuster and make a determination            as to whether the invoice is auto approved or adjuster            approved. If an invoice is auto approved, the invoice will            always be assigned to a processor for payment without it            ever being sent to an adjuster for approval.    -   1.6.2 Data Fields to Assist with Future Releases or Customer        Integration        -   It must be possible to capture the following information at            some point in the future because of either planned future            releases or customer integration.            -   Amount Being Paid on Each Invoice    -   1.6.3 Claim Number is Editable on the Invoice        -   If a company is set up for EDI transmission of invoices to            the company's claim system, that company must have the            ability to change the claim number on the invoice.

1.7 Extension Points

-   -   1.7.1 MA-19—View Customer File        -   The View Customer File Functional Specification is used to            review the rental history in regards to a specific rental.            Upon completion of the View Customer File Functional            Specification, the ADJUSTER should be returned to step one            of Section 1.4.2.1, Individual Pay, or Section 1.4.2.2, Bulk            Pay in the Handle Unapproved Invoices Functional            Specification. Any previously approved invoices should still            be approved in the system.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Invoicing—Individual Payment List

-   -   This screen will allow the user to enter a check number for each        invoice and notify Enterprise that they have processed the        payment.    -   2.1.1 Individual Payment List—see FIG. 137    -   2.1.2 Individual Payment List

Screen Label Type Size Screen Field Name Data Field Screen Specific RuleClaim Number Input 15 Claim Number Insurance Claim Will be pre-filledwith Number claim number currently on authorization. This field isrepeated for each invoice in the payment list. This field is repeatedfor each invoice in the payment list. Invoice Date Output 10 InvoiceDate Record Add Date This field is repeated for (ECARS Ticket Date) eachinvoice in the payment list. Please include Output 20 Invoice ID InvoiceNumber Rental Group ID + this reference Rental Branch ID + number onECARS Ticket number. your check: This field is repeated for each invoicein the payment list. Invoice: Output 20 Invoice Id Invoice Number RentalGroup Id + Rental Branch Id + ECARS Ticket Number This field is repeatedfor each invoice in the payment list. Federal ID Output 30 Location'sFederal ID Federal ID This field is repeated for Number each invoice inthe payment list. Total Amount: Output 15,2 Total amount due TotalAmount Total Charges − Amount from Ins. Company Due Received This fieldis repeated for each invoice in the payment list. Handling For: Output30 Handling for First Name + Adjuster's First name + Adjuster's NameLast Name Adjuster's last name. The name of the adjuster to which theinvoice is currently assigned. Output 30 Insured's Name First Name +This field is repeated for Last Name each invoice in the payment list.Output 30 Rental Location's Address Line + This field is repeated forMailing Street Address Line2 each invoice in the Address payment list.Output 12 Rental Location Telephone This field is repeated for TelephoneNumber Number each invoice in the payment list. Output 30 RentalLocation's City + State + Zip This field is repeated for Mailing City,State Code each invoice in the and Zip Code payment list. Output 30Rental Location's City + State + Zip This field is repeated for MailingCity State Code each invoice in the and Zip payment list. Output 30Rental Location's Address Line + This field is repeated for MailingStreet Address Line2 each invoice in the Address payment list. Date ofloss Output 10 Date of loss Date Of Loss This field is repeated for eachinvoice in the payment list. Invoice Output 5 Invoice List NumberCALCULATED This field is repeated for each invoice in the payment list.Count Claim type Output 10 Claim Type claim type This field is repeatedfor description each invoice in the payment list. Claims Office: Output3 Office Id external This claims office id organization which the useris abbreviated currently process work name for. Vehicle Output 10 LossType loss type This field is repeated for Condition description eachinvoice in the payment list. Remit to: Output 30 Rental Location'saccounting name This field is repeated for Accounting Name each invoicein the payment list. Send Payment Output 30 Rental Location's accountingname This field is repeated for to: Accounting Name each invoice in thepayment list. Rental: Output 30 Rental Location's accounting name Thisfield is repeated for Accounting Name each invoice in the payment list.Enter the Input 20 Check Number check number This field is repeated forcheck number each invoice in the of your payment list. payment here:

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 PRINTER FRIENDLY PAGE            -   When clicked, the user will be taken to the “Printer                Friendly View” of the current invoice.        -   2.1.3.2 CONFIRM PAYMENT            -   When clicked, system will mark the reservation as paid                and update the database. The update will be passed to                the Arms system.        -   2.1.3.3 PAY LATER            -   When clicked, the user will be returned to their action                item list and the payment list will remain unprocessed.        -   2.1.3.4 RETURN TO ADJUSTER            -   When clicked, the invoice will be returned to the last                adjuster associated with the rental before it closed.                The invoice will be removed from the list displayed.        -   2.1.3.5 Top of Page            -   When clicked, the user will be taken to the top of the                current invoice page.

2.2 Bulk Payment List

-   -   This screen will allow the user to pick which functions that        he/she may want to change.    -   2.2.1 Screen Layout—Bulk Payment List—see FIG. 138        -   2.2.2 Invoicing—Bulk Payment List

Screen Label Type Size Screen Field Name Data Field Screen Specific RuleClaim Number Input 15 Claim Number Insurance Claim Will be pre-filledwith Number claim number currently on authorization. This field isrepeated for each invoice in the payment list. Invoice Date Output 10Invoice Date Record Add Date This field is repeated for (ECARS Ticketeach invoice in the Date) payment list. Please include Output 20 InvoiceID Invoice Number Rental Group ID + this reference Rental Branch ID +number on ECARS Ticket number. your check: This field is repeated foreach invoice in the payment list. Invoice: Output 20 Invoice Id InvoiceNumber Rental Group Id + Rental Branch Id + ECARS Ticket Number. Thisfield is repeated for each invoice in the payment list. Federal IDOutput 30 Location's Federal ID This field is repeated for Federal IDNumber each invoice in the payment list. Total Amount: Output 152 Totalamount due Total Amount Total Charges − Amount from Ins. Company DueReceived. This field is repeated for each invoice in the payment list.Handling For: Output 30 Handling for First Name + Adjuster's Firstname + Adjuster's Name Last Name Adjuster's last name. The name of theadjuster to which the invoice is currently assigned. Output 30 Insured'sName Last Name This field is repeated for each invoice in the paymentlist. Output 30 Rental Location's Address Line + This field is repeatedfor Mailing Street Address Line2 each invoice in the Address paymentlist. Output 12 Rental Location Telephone This field is repeated forTelephone Number Number each invoice in the payment list. Output 30Rental Location's City + State + Zip This field is repeated for MailingCity, State Code each invoice in the and Zip Code payment list. Output30 Rental Location's City + State + Zip This field is repeated forMailing City State Code each invoice in the and Zip payment list. Output30 Rental Location's Address Line + This field is repeated for MailingStreet Address Line2 each invoice in the Address payment list. Date ofloss Output 10 Date of loss Date Of Loss This field is repeated for eachinvoice in the payment list. Invoice Output 5 Invoice List CALCULATEDThis field is repeated for Number each invoice in the payment list.Claim type Output 10 Claim Type claim type This field is repeated fordescription each invoice in the payment list. Claims Office: Output 3Office Id external This claims office id organization which the user isabbreviated currently process work name for. Vehicle Output 10 Loss Typeloss type This field is repeated for Condition description each invoicein the payment list. Remit to: Output 30 Rental Location's accountingname This field is repeated for Accounting Name each invoice in thepayment list. Send Payment Output 30 Rental Location's accounting nameThis field is repeated for to: Accounting Name each invoice in thepayment list. Rental: Output 30 Rental Location's accounting name Thisfield is repeated for Accounting Name each invoice in the payment list.

-   -   2.2.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.2.3.1 PRINTER FRIENDLY PAGE            -   When clicked, the user will be taken to the “Printer                Friendly View” of the current invoice.        -   2.2.3.2 CONFIRM PAYMENT            -   When clicked, system will mark the reservation as paid                and update the database. The update will be passed to                the Arms system.        -   2.2.3.3 PAY LATER            -   When clicked, the user will be returned to their action                item list and the payment list will remain unprocessed.        -   2.2.3.4 RETURN TO ADJUSTER            -   When clicked, the invoice will be returned to the last                adjuster associated with the rental before it closed.                The invoice will be removed from the list displayed.        -   2.2.3.5 Top of Page            -   When clicked, the user will be taken to the top of the                current invoice page.

2.3 Return Invoice to Adjuster

-   -   2.3.1 Screen Layout—returnBilling.shtml—see FIG. 139    -   2.3.2 Return Billing

Screen Label Type Size Screen Field Name Data Field Screen Specific RuleClaim Number Input 15 Claim Number Insurance Claim Number Amount Output15,2 Total Amount Due Total Amount from Ins. Company Due Adjuster'sOutput 30 Adjuster's Name First Name + Adjuster's last name + Name LastName adjuster's first name Comments Input 50 Reason Comments NOTE RenterName Output 30 Renter's name First Name + Renter's Last Name + Last NameRenter's First Name Reason For ComboBox 50 Reason For Return standardReturn message description

-   -   2.3.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.3.3.1 CANCEL            -   When clicked, the user will be returned to the Invoicing                Approval or Invoicing Individual Payment screen from                which they came. The invoice will still be displayed                with the status of the invoice unchanged.        -   2.3.3.2 Return to Adjuster            -   When clicked, the user will return the invoice to the                Adjuster for further instructions and the status will                show returned invoice.

3. Application Operations

-   -   This section will detail all the application operations that are        part of this Functional Specification Document.

3.1 Get Approved Invoices (Office Id)

-   -   The get approved invoices operation finds all the approved        invoices for the specified office.

3.2 Get Invoice Detail (Invoice Number)

-   -   The get invoice detail operation gets the relevant invoice        information for the specified invoice number.

3.3 Return Invoice to Approving Adjuster (Invoice Number, Reason Code)

-   -   The return invoice to approving adjuster operation marks the        specified invoice so that the approving adjuster can review the        invoice and re-approve it.

3.4 Pay Invoice (Invoice Number, Check Number)

-   -   The pay invoice operation records the check number specified by        the adjuster against the specified invoice and marks the invoice        as paid.

4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 accounting name

Entity OFFDRB OFFICE DIRECTORY BRANCH MASTER Column Name acctg_nam LabelName Accounting Name System Name Data Type VARCHAR(8) AttributeDefinition

-   -   4.1.2 action item complete date

Entity ACTION ITEM Column Name actn_item_cmpl_dte Label Name action itemcomplete date: System Name AITMCMPLDT Data Type DATE AttributeDefinition The action item complete date is the date the action item wascompleted by an administrator or adjustor.

-   -   4.1.3 action item effective date

Entity ACTION ITEM Column Name actn_item_eff_dte Label Name action itemeffective date: System Name AITMEFFDT Data Type DATE AttributeDefinition The action item effective date is the date the action itemwill become effective.

-   -   4.1.4 action item status code

Entity ACTION ITEM Column Name actn_item_stat_cde Label Name action itemstatus code: System Name Data Type CHAR(6) Attribute Definition Theaction item status code defines the status of this action item. Forexample:

-   -   4.1.5 action item type code

Entity ACTION ITEM Column Name actn_item_typ_cde Label Name action itemtype code: System Name Data Type DEC(3, 0) Attribute Definition Theaction item type code defines specific tasks/action items associatedwith the Rental Authorization/Reservation activities accomplished byadjustors and administrators when contracting an insured with areplacement vehicle. For example: Closing an Of

-   -   4.1.6 action item type description

Entity ACTION ITEM TYPE Column Name actn_item_typ_dsc Label Name actionitem type description: System Name Data Type CHAR(40) AttributeDefinition The action item type description is a lexical definition ofan action item type code which defines specific tasks/action itemsassociated with the Rental Authorization/Reservation activitiesaccomplished by adjustors and administrators when contracting an

-   -   4.1.7 Address Line

Entity ARM: Rental Location Master Column Name LOADL1 Label Name SystemName Data Type CHAR(30) Attribute Definition

-   -   4.1.8 Address Line2

Entity ARM: Rental Location Master Column Name LOADL2 Label Name AddressLine System Name Data Type CHAR(30) Attribute Definition

-   -   4.1.9 ARMS Profile ID

Entity ACTION ITEM Column Name ALCUID Label Name ARMS Profile ID SystemName Data Type CHAR(5) Attribute Definition The ARMS Profile ID is thecompany identifier used to uniquely define an authorization.

-   -   4.1.10 assigned to adjustor code

Entity ACTION ITEM Column Name assgn_to_adjr_cde Label Name AdjustorCode System Name AADJRCDE Data Type CHAR(10) Attribute Definition Theassigned to adjustor code is the adjustor code of the administrator oradjustor's who is assigned the action item.

-   -   4.1.11 assigned to company identifier

Entity ACTION ITEM Column Name assgn_to_cmpy_id Label Name ARMS ProfileID System Name ACMPYID Data Type CHAR(5) Attribute Definition Theassigned to company identifier is the company identifier of theadministrator or adjustor's who is assigned the action item.

-   -   4.1.12 Bill To %

Entity ARM: Authorization(Claim Info) Column Name AZBTPC Label Name BillTo % System Name Data Type DECIMAL(3) Attribute Definition

-   -   4.1.13 Branch

Entity A4 Cross Reference Column Name br_id Label Name Branch: SystemName Data Type CHAR(2) Attribute Definition

-   -   4.1.14 check number

Entity RENTAL INVOICE PAYMENT Column Name chk_nbr Label Name checknumber: System Name CHKNBR Data Type DEC(11, 0) Attribute Definition

-   -   4.1.15 City

Entity ARM: Rental Location Master Column Name LOCYNM Label Name CitySystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.16 claim type description

Entity CLAIM TYPE Column Name clm_typ_dsc Label Name claim typedescription: System Name CLMTYPDSC Data Type CHAR(40) AttributeDefinition The claim type description is a lexical definition of theclaim type code which defines the different Authorization claim types.For example: Insured, Claimant, Uninsured Motorist, etc.

-   -   4.1.17 company identifier

Entity EXTERNAL ORGANIZATION Column Name cmpy_id Label Name companyidentifier: System Name CMPYID Data Type DEC(11, 0) Attribute DefinitionBusiness Party Identifier is a surrogate key assigned to each uniqueoccurrence of an Individual, External Organization, and InternalOrganization (Business Party).

-   -   4.1.18 company structure level code

Entity ACTION ITEM Column Name cmpy_strct_lvl_cde Label Name companystructure level code: System Name CMPYSLVLCD Data Type DEC(3, 0)Attribute Definition The external organization structure level codeidentifies the kind or type of internal organizations of the externalorganizations which Enterprise Rent-A-Car does business with. Such as:Corporation, Branch Claims Office, Region, Area, Subregion, etc.

-   -   4.1.19 Customer Transaction ID

Entity ACTION ITEM Column Name AZCUTI Label Name Customer Transaction IDSystem Name Data Type CHAR(20) Attribute Definition The CustomerTransaction ID is the authorization transaction identifier which alongwith a company identifier uniquely define an authorization.

-   -   4.1.20 Date Of Loss

Entity ARM: Renter Detail Column Name RKLSDT Label Name Date of LossSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.21 Dollars Per Day Covered

Entity ARM: Authorization(Claim Info) Column Name AZ$PDY Label NameDollars Per Day Covered System Name Data Type DECIMAL(5, 2) AttributeDefinition

-   -   4.1.22 End Date

Entity ARM: Authorization(Claim Info) Column Name AZENDT Label Name EndDate System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.23 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute Definition External Organization Abbreviated Name isa shortened text based label associated with an organization outside ofEnterprise. This name is sometimes used for accounting purposes.

-   -   4.1.24 external organization identifier

Entity EXTERNAL ORGANIZATION Column Name e_o_id Label Name externalorganization identifier: System Name EOID Data Type DEC(11, 0) AttributeDefinition The external organization identifier is a surrogate keyassigned to each unique occurrence of an External Organization.Examples: body shops, vehicle manufacturers, insurance companies,leasing accounts, credit unions, dealerships, or governing agencies.

-   -   4.1.25 Federal ID Number

Entity A4 Invoice Header Column Name I1FETX Label Name Federal ID NumberSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.26 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.27 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.28 Group

Entity A4 Cross Reference Column Name grp_id Label Name Group NumberSystem Name Data Type CHAR(2) Attribute Definition

-   -   4.1.29 handled by adjustor code

Entity ACTION ITEM Column Name handl_by_adjr_cde Label Name AdjustorCode System Name HNDADJRCDE Data Type CHAR(10) Attribute Definition Thehandled by adjustor code is the adjustor code of the administrator oradjustor's who is handling the action item.

-   -   4.1.30 handled by company identifier

Entity ACTION ITEM Column Name handl_by_cmpy_id Label Name ARMS ProfileID System Name HNDCMPYID Data Type CHAR(5) Attribute Definition Thehandled by company identifier is the company identifier of theadministrator or adjustor's who is handling the action item.

-   -   4.1.31 handling for adjustor code

Entity AUTHORIZATION ACTIVITY LOG Column Name handl_for_adtr_cde LabelName handling for adjustor code: System Name HNDADJRCDE Data TypeCHAR(10) Attribute Definition The handling for adjustor coder is theadjustor code of an adjustor/user who is handling authorizationactivities for another adjustor/user in the ARMS Web application.

-   -   4.1.32 handling for company identifier

Entity AUTHORIZATION ACTIVITY LOG Column Name handl_for_cmpy_id LabelName handling for company identifier: System Name HNDCMPYID Data TypeCHAR(5) Attribute Definition The handling for company identifier is thecompany identifier used to uniquely identify an adjustor/user who ishandling authorization activities for another adjustor/user in the ARMSWeb application.

-   -   4.1.33 Insurance Claim Number

Entity A4 Invoice Header Column Name I1CLNO Label Name Insurance ClaimNumber System Name Data Type CHAR(20) Attribute Definition

-   -   4.1.34 Insurance Claim Number

Entity ARM: Authorization(Claim Info) Column Name AZCLNO Label NameInsurance Claim Number System Name Data Type CHAR(20) AttributeDefinition

-   -   4.1.35 Invoice Number

Entity A4 Invoice Header Column Name I1INNO Label Name Invoice NumberSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.36 Item Amount

Entity A4 Invoice Detail Column Name I2IT$$ Label Name Item AmountSystem Name Data Type DECIMAL(7.2) Attribute Definition

-   -   4.1.37 Item Description

Entity A4 Invoice Detail Column Name I2ITDS Label Name Item DescriptionSystem Name Data Type CHAR(30) Attribute Definition

-   -   4.1.38 Item Quantity

Entity A4 Invoice Detail Column Name I2ITQY Label Name Item QuantitySystem Name Data Type DECIMAL(5) Attribute Definition

-   -   4.1.39 Item Rate

Entity A4 Invoice Detail Column Name I2ITRT Label Name Item Rate SystemName Data Type DECIMAL(7.2) Attribute Definition

-   -   4.1.40 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.41 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.42 loss type description

Entity LOSS TYPE Column Name loss_typ_dsc Label Name loss typedescription: System Name LOSSTYPDSC Data Type CHAR(40) AttributeDefinition The loss type description is a lexical definition of the losstype code which defines the different loss categories when an InsuranceCompany authorizes a Rental. For example: Theft, Drivable, Repairable,Non-drivable, Non-repairable, Totaled.

-   -   4.1.43 Max $ Covered

Entity ARM: Authorization(Claim Info) Column Name AZ$MAX Label Name Max$ Covered System Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.44 NOTE

Entity ARM: ARMS/400 Diary Notes File Column Name NENOTE Label Name NOTESystem Name Data Type CHAR(50) Attribute Definition

-   -   4.1.45 Record Add Date

Entity A4 Invoice Header Column Name I1ADDT Label Name Record Add DateSystem Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.46 related office identifier

Entity ACTION ITEM Column Name rel_ofc_id Label Name related officeidentifier: System Name RELOFCID Data Type DEC(11, 0) AttributeDefinition The related office identifier is the identifier of the officeresponsible for the action item.

-   -   4.1.47 Request Type

Entity ACTION ITEM TYPE Column Name X4RSFG Label Name Request TypeSystem Name Data Type CHAR(1) Attribute Definition

-   -   4.1.48 standard message description

Entity STANDARD MESSAGE Column Name std_msg_dsc Label Name standardmessage description: System Name STDMSGDSC Data Type CHAR(50) AttributeDefinition The standard message description is a lexical definition forstandard message code which defines a predefined message which isapplicable to specific activity type codes. For example: “Authorizationconfirmed on &Date with Reservation Number &Resnumber”

-   -   4.1.49 Start Date

Entity ARM: Authorization(Claim Info) Column Name AZSTDT Label NameStart Date System Name Data Type NUMERIC(8) Attribute Definition

-   -   4.1.50 State

Entity ARM: Rental Location Master Column Name LOSACD Label Name StateSystem Name Data Type CHAR(2) Attribute Definition

-   -   4.1.51 Status Code

Entity ACTION ITEM TYPE Column Name XUSTCD Label Name Status Code SystemName XUSTCD Data Type CHAR(1) Attribute Definition The status code is acode from the ARMS system which identifies whether an authorization is areservation, a ticket, unauthorized, invoiced, paid, etc.

-   -   4.1.52 Telephone Number

Entity ARM: Rental Location Master Column Name LOPHNO Label NameTelephone Number System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.53 Ticket Number

Entity A4 Cross Reference Column Name X4TKNO Label Name Ticket NumberSystem Name Data Type CHAR(6) Attribute Definition

-   -   4.1.54 Total Amount Due

Entity A4 Invoice Trailer Column Name I3BL$$ Label Name Total Amount DueSystem Name Data Type DECIMAL(9, 2) Attribute Definition

-   -   4.1.55 Total Amount Received

Entity A4 Invoice Trailer Column Name I3RC$$ Label Name Total AmountReceived System Name Data Type DECIMAL(9.2) Attribute Definition

-   -   4.1.56 Total Billed to Others

Entity A4 Invoice Trailer Column Name I3OT$$ Label Name Total Billed toOthers System Name Data Type DECIMAL(9.2) Attribute Definition

-   -   4.1.57 Total Ticket Charges

Entity A4 Invoice Trailer Column Name I3TO$$ Label Name Total TicketCharges System Name Data Type DECIMAL(9.2) Attribute Definition

-   -   4.1.58 Zip Code

Entity ARM: Rental Location Master Column Name LOZPCD Label Name ZipCode System Name Data Type CHAR(9) Attribute Definition

5. Questions and Answers

-   -   None.

Functional Design Specification Reject an Invoice Version 1.0 1. RejectAn Invoice Use Case 1.1 Brief Description

-   -   The Reject an Invoice use case describes how the ADJUSTER would        reject an invoice to Enterprise in the ARMS Web system.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:        -   ADJUSTER—The ADJUSTER will use this use case to reject an            invoice.

1.3 Pre-Conditions

-   -   The ADJUSTER'S office must be set up for individual approval of        invoices.    -   The ADJUSTER must be set up to approve invoices.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps for an        ADJUSTER to reject invoices.    -   1.4.1 Activity Diagram—see FIG. 140    -   1.4.2 Basic Flow        -   1. The ADJUSTER will reject an invoice.        -   2. The system will prompt for reject confirmation.        -   3. The ADJUSTER will enter a reject reason for rejecting the            invoice.        -   4. The ADJUSTER may enter comments to be added to the diary            notes.        -   5. The ADJUSTER will submit the rejection to the system.        -   6. The system will display instructions for achieving            resolution on the rejected invoice.        -   7. The ADJUSTER will acknowledge that they understand the            instructions.        -   8. The system will update the ARMS Web database to reflect            that the ADJUSTER rejected the invoice.        -   9. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Cancel Rejection            -   At steps two through seven of the Basic Flow, the                ADJUSTER must have the ability to cancel the invoice                rejection process. Canceling the rejection should return                the ADJUSTER to the Invoicing Approval Screen or the                Invoicing Individual Payment screen. The invoice that                was to be rejected should be displayed. The status of                the invoice should be unapproved.        -   1.4.3.2 No Reject Reason Given            -   At step three in the Basic Flow; if the ADJUSTER                attempts to bypass entering a reject reason, they will                be prompted to enter one. The ADJUSTER will not be                allowed to complete the rejection process without                providing a reject reason.        -   1.4.3.3 Short Pay            -   If the reject reason given in step three of the Basic                Flow is a reason that requires a short pay, at step five                of the Basic Flow the system will display a field for                entry of the short pay amount. The ADJUSTER will not be                allowed to complete the rejection process without                providing an amount that will be paid.

1.5 Post-Conditions

-   -   If the use case was successful the invoice will be marked        rejected in the ARMS Web system.    -   If the use case was unsuccessful, the status remains unchanged.

1.6 Special Requirements

-   -   The additional requirements of the business use case are        included here. These are requirements not covered by the flow as        they have been described in the sections above.    -   1.6.1 Invoices are Initially Auto Approved        -   If an ADJUSTER'S invoices are normally auto approved,            functionality needs to exist to route invoices to them when            they are returned to ADJUSTER from the PROCESSOR. This            functionality will need to override the normal routing            processes that exist at the office.

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Reject Billing Reason

-   -   This screen will allow the user to begin the rejection process.    -   2.1.1 Screen Layout—Reject Billing Reason—see FIG. 141    -   2.1.2 Reject Billing—Reject Billing Reason

Screen Field Screen Label Type Size Name Data Field Screen Specific RuleAmount Output 10 Total Amount Due CALCULATED Claim Number Output 15Claim Number Insurance Claim Number Adjuster's Name Output 30 Adjuster'sName First Name + Name of adjuster's to which Last Name the invoice isassigned Comments Input 50 Message Text NOTE Renter's Name Output 30Renter's name First Name + Renter's Last Name + Last Name Renter's FirstName Reason for List Box 20 Rejection Reasons standard Rejection messagedescription

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 CONTINUE            -   The system will validate the input from the screen                according to the listed business rules. If the                validation passes, the rejection process will continue.            -   The following business rules that must be passed before                the USER may continue to the next step in the rejection                process are the following:                -   A valid rejection reason must be selected from the                    drop down box                -   If the rejection reason selected is “Other” a                    comment must be entered        -   2.1.3.2 CANCEL            -   When clicked, the user will be returned to the Invoicing                Approval or Invoicing Individual Payment screen. The                invoice will still be displayed with the status of the                invoice unchanged.

2.2 Reject Billing Amount

-   -   2.2.1 Screen layout—Reject Billing Amount—see FIG. 142    -   2.2.2 Reject Billing—Reject Billing Amount

Screen Field Screen Label Type Size Name Data Field Screen Specific RuleClaim Number Output 15 Claim Number Insurance Claim Number Amount Output15.2 Invoice Amount Total Amount Due Adjuster's Name Output 30Adjuster's Name First Name + Name of adjuster's to which Last Name theinvoice is assigned. Handling For: Output 30 Handling for First Name +Adjuster's First name + Adjuster's Name Last Name Adjuster's last name.The name of the adjuster to which the invoice is currently assigned.Output 30 User's Name First Name + Adjuster's last name + Last NameAdjuster's first name. The name of the adjuster to which the invoice iscurrently assigned. Output 30 Rental Location Address Line + AddressAddress Line2 Output 30 Rental Location City + State + City, State andZip Zip Code Output 15 Rental Location Telephone Telephone Number NumberRenter's Name Output 30 Renter's name First Name + Renter's Last Name +Last Name Renter's First Name To complete this Output 50 Rental Locationaccounting process, please Accounting Name name contact the EnterpriseBranch listed below:

-   -   2.2.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.2.3.1 REJECT INVOICE            -   The system will validate the input from the screen. If                the validation passes, the invoice will be marked as                rejected and the Arms Web database will be updated. If                an amount was entered in the “Amount you are paying”                field, then the invoice should be marked short paid.        -   2.2.3.2 CANCEL            -   When clicked, the user will be returned to the Invoicing                Approval or Invoicing Individual Payment screen. The                invoice will still be displayed with the status of the                invoice unchanged.

3. Application Operations

-   -   This section will detail all the application operations that are        part of this Functional Specification Document.

3.1 Get Invoice Rejection Reasons (Company Id)

-   -   The get invoice rejection reasons gets the predefined rejection        reasons for the company.

3.2 Reject Invoice (Invoice Number)

-   -   The reject invoice operation marks the specified invoice as        rejected. The rejected invoice becomes an action item for the        adjuster to handle.

4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 accounting name

Entity OFFDRB OFFICE DIRECTORY BRANCH MASTER Column Name acctg_nam LabelName Accounting Name System Name Data Type VARCHAR(8) AttributeDefinition

-   -   4.1.2 Address Line

Entity ARM: Rental Location Master Column Name LOADL1 Label Name SystemName Data Type CHAR(30) Attribute Definition

-   -   4.1.3 Address Line2

Entity ARM: Rental Location Master Column Name LOADL2 Label Name AddressLine System Name Data Type CHAR(30) Attribute Definition

-   -   4.1.4 City

Entity ARM: Rental Location Master Column Name LOCYNM Label Name CitySystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.5 external organization abbreviated name

Entity EXTERNAL ORGANIZATION Column Name e_o_abbr_nam Label Nameexternal organization abbreviated name: System Name EOABBRNAM Data TypeCHAR(10) Attribute Definition External Organization Abbreviated Name isa shortened text based label associated with an organization outside ofEnterprise. This name is sometimes used for accounting purposes.

-   -   4.1.6 First Name

Entity ARM: Adjustor Master Column Name ALFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.7 First Name

Entity ARM: Renter Detail Column Name RKFSNM Label Name First NameSystem Name Data Type CHAR(15) Attribute Definition

-   -   4.1.8 Insurance Claim Number

Entity A4 Invoice Header Column Name I1CLNO Label Name Insurance ClaimNumber System Name Data Type CHAR(20) Attribute Definition

-   -   4.1.9 Last Name

Entity ARM: Adjustor Master Column Name ALLSNM Label Name Last NameSystem Name Data Type CHAR(20) Attribute Definition

-   -   4.1.10 Last Name

Entity ARM: Renter Detail Column Name RKLSNM Label Name Last Name SystemName Data Type CHAR(20) Attribute Definition

-   -   4.1.11 standard message description

Entity STANDARD MESSAGE Column Name std_msg_dsc Label Name standardmessage description: System Name STDMSGDSC Data Type CHAR(50) AttributeDefinition The standard message description is a lexical definition forstandard message code which defines a predefined message which isapplicable to specific activity type codes. For example: “Authorizationconfirmed on &Date with Reservation Number &Resnumber”

-   -   4.1.12 State

Entity ARM: Rental Location Master Column Name LOSACD Label Name StateSystem Name Data Type CHAR(2) Attribute Definition

-   -   4.1.13 Telephone Number

Entity ARM: Rental Location Master Column Name LOPHNO Label NameTelephone Number System Name Data Type NUMERIC(10) Attribute Definition

-   -   4.1.14 Total Amount Due

Entity A4 Invoice Trailer Column Name I3BL$$ Label Name Total Amount DueSystem Name Data Type DECIMAL(9,2) Attribute Definition

-   -   4.1.15 Zip Code

Entity ARM: Rental Location Master Column Name LOZPCD Label Name ZipCode System Name Data Type CHAR(9) Attribute Definition

Functional Design Specification Callbacks Version 1.1 Callbacks 1.Callbacks 1.1 Brief Description

-   -   This use case describes the process that will perform repair        facility callbacks in the ARMS Web system. USERs perform repair        facility callbacks on each of the rental contracts that are set        to expire in the near future (or have already expired), to        proactively determine if rentals must be extended due to        slippage in repair facility time estimates. The callback process        in the ARMS Web system will retrieve each of the rental        contracts that will expire in the user-defined period of time,        and organize them by repair facility to allow the USER to make        one phone call to inquire about the potentially multiple        vehicles that the repair facility is responsible for.

1.2 Use Case Actors

-   -   All actors will use the use case to retrieve callback lists in        the ARMS Web system. All of the following actors can be defined        generically as a USER:        -   PROCESSOR        -   ADJUSTER        -   COMPANY MANAGER    -   For the balance of this use case, all of the above actors will        be referred to as USER.

1.3 Pre-Conditions

-   -   The USER must be signed-on to the system.

1.4 Flow of Events

-   -   The Flow of Events includes all the steps necessary to retrieve        and manage callbacks in the ARMS Web system.    -   1.4.1 Activity Diagram—see FIG. 143    -   1.4.2 Basic Flow        -   The Basic Flow of the Callbacks use case includes all of the            required activities for the USER to successfully generate            and perform repair facility callbacks in the ARMS Web            system.        -   1. The USER selects to perform callbacks from the reporting            menu of top navigation.        -   2. The system generates a report of all open authorizations            for the selected office that will expire the next day (have            a last authorized day of tomorrow). This list will include            any authorizations that have already expired, or will expire            by the end of business on the following day.        -   3. The system displays a summary of repair facilities that            have rentals expiring in the specified timeframe. The repair            facility callback summary must consist of:            -   Repair Facility Name            -   Repair Facility Telephone Number            -   Number of Rental callbacks due to the Repair Facility        -   4. The USER selects one or more repair facilities from the            repair facility callback summary.        -   5. The system displays a summary of the open authorizations            that are set to expire for all selected repair facilities.            The open authorization callback summary will consist of:            -   Renter Name            -   Year/Make/Model of the Renter's Vehicle            -   Driveable Flag (y/n)            -   Number of Days Behind            -   Authorized Days            -   Last Authorized Day        -   6. The USER will select a customer file from the list.        -   7. The USER will extend into use case MA-12 Extend            Authorization. The USER will have the ability to extend, add            notes, terminate or modify an authorization as proscribed in            the MA-12 Extend Authorization use case. If callbacks still            exist, the USER will be returned to Step 5 of the Basic Flow            on completion of the MA-12 Extend Authorization use case. If            all callbacks have been completed, the Basic Flow continues.        -   8. The system will display a screen to indicate that all            repair facility callbacks for the office have been            completed.        -   9. This ends this use case.    -   1.4.3 Alternative Flows        -   The Alternative Flows of this use case can occur when            certain conditions exist or when specific USER feedback is            provided.        -   1.4.3.1 Change Last Authorized Date            -   At Step 3 or Step 5 of the Basic Flow, the USER has the                ability to change the last authorized day to any day in                the future. The system will re-generate the callbacks                list and the USER will be returned to Step 2 of the                Basic Flow on submission of the new last authorized day.        -   1.4.3.2 Last Authorized Date Entered Invalid            -   In the Change Last Authorized Date Alternative Flow, if                the last authorized date entered by the USER is invalid,                the system will return to the beginning of the Change                Last Authorized Date Alternative Flow and provide the                USER with an error message.            -   1.4.3.2.1 It will be considered invalid if the last                authorized date entered is less than the current date.

1.5 Post-Conditions

-   -   If successful, a callback list is created for the USER.    -   If unsuccessful, the system state remains unchanged.

1.6 Special Requirements

-   -   None.

1.7 Extension Points

-   -   1.7.1 MA-12 Extend Authorization        -   At Step 7 of the Basic Flow, the USER will extend from the            use case to the MA-12 Extend Authorization use case. This            will allow the USER to update the open authorization with            the results of the repair facility callback (e.g., extend,            add notes, or terminate the rental authorization). On            completion of the MA-12 Extend Authorization use case, the            rules specified within the Basic Flow should be followed as            to the next step in the process.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Repair Facility Callback Summary

-   -   This screen provides the USER with a repair facility callback        summary, and supports Step 3 of the Basic Flow.    -   2.1.1 Screen Layout—see FIG. 144

Functional Design Specification Generate Personal Report Version 1.11Generate Personal Report 1. Generate Personal Report 1.1 BriefDescription

-   -   This use case describes how a USER would generate a report on        their personal rental management activity. Personal reports        allow the USER access to reporting on only their own rental        management activity, which allows the USER to review their own        performance and secures access to the rental management reports        of others.

1.2 Use Case Actors

-   -   All actors will use the use case to generate personal reports in        the ARMS Web system. All of the following actors can be defined        generically as a USER:        -   ADJUSTER        -   PROCESSOR        -   COMPANY MANAGER    -   For the balance of this use case, all of the above actors will        be referred to as USER.

1.3 Pre-Conditions

-   -   The USER must be signed-on to the system.

1.4 Flow of Events

-   -   The Flow of Events includes all the steps necessary to generate        personal reports in the ARMS Web system.    -   1.4.1 Activity Diagram—see FIG. 145    -   1.4.2 Basic Flow        -   The Basic Flow of the Generate Personal Report use case            includes all of the required activities for the USER to            successfully generate and view a standard personal report in            ARMS Web.        -   1. The USER selects to generate a personal report from the            top navigation bar.        -   2. The system generates the report for the specific USER.            The report should provide rental management reports for the            signed-in USER. The default report view to display to the            USER will be the Open Ticket Detail view (see section 1.6.1            of the Special Requirements section on page 5 for further            definition).        -   3. The system displays the report to the USER.        -   4. This ends this use case.    -   1.4.3 Alternative Flows        -   The Alternative Flows of this use case can occur when            certain conditions exist or when specific USER feedback is            provided. The Alternative Flows are optional and only occur            if the conditions specified are met.        -   1.4.3.1 Change Report View            -   At Step 3 of the Basic Flow, the USER will have the                ability to change the report ‘view’. (Report views are                covered in more detail in Section 1.6 Special                Requirements.) Report ‘views’ change the type of                information that is presented to the USER, but maintains                the same or similar scope. For example, the USER can                select to change to a closed ticket detail view from the                open ticket detail view, but the information presented                is limited (scoped) to the rental management activity of                the USER.            -   If the USER selects to change the report view, the                system will return to Step 2 of the Basic Flow and                re-generate the report to build the requested view.        -   1.4.3.2 Change Closed Ticket Date Range            -   At Step 3 of the Basic Flow, if the current report view                is a closed ticket report, the USER will have the                ability to change the date range of the report. The                available date range for closed ticket reporting will be                a rolling 13-month period (to be expanded to 24-months                in future releases) with the current month inclusive.                The default date range that will be presented to the                USER will be the current and previous two (2) months.                The USER will have the ability to select Month/Year to                begin and end the date range for the closed ticket                report. The USER will not have the ability to select                specific days within a month as part of the date range.            -   If the USER selects a new date range for the closed                ticket report view, the system will return to Step 2 of                the Basic Flow and re-generate the report to build the                USERs closed ticket report for the selected date range.        -   1.4.3.3 Select Open Ticket from Open Ticket Detail Report            -   At Step 3 of the Basic Flow, if the current report view                is an open ticket detail report, the USER will have the                ability to select a report line item to view the details                of the open ticket customer file. When selected, the                system will present the USER with the customer file that                corresponds to the selected open ticket. The USER will                be allowed to modify and submit changes to the customer                file (as proscribed in use case MA-13 Change                Authorization). Once activity on the customer file is                complete, the USER should be returned to the open ticket                detail report (Step 3 of the Basic Flow).        -   1.4.3.4 Select Closed Ticket from Closed Ticket Detail            Report            -   At Step 3 of the Basic Flow, if the current report view                is a closed ticket detail report, the USER will have the                ability to select a report line item to view the details                of the closed ticket customer file. When selected, the                system will present the USER with the closed customer                file that corresponds to the selected closed ticket. The                USER will be allowed to view/print the details of the                closed ticket, but will not have the ability to modify                or change the ticket information. From the closed                customer file, the USER will be returned to the closed                ticket detail report (Step 3 of the Basic Flow).        -   1.4.3.5 Sort Report            -   At Step 3 of the Basic Flow, the USER will have the                ability to select any report column heading to have the                report sorted by the selected column. If the USER                selects a column heading, the system must sort the                report by the selected column heading in ascending                order. The USER will have the ability to toggle between                ascending and descending sort order by re-selecting the                currently sorted column. For example, if the USER wanted                their report view to be sorted by Renter Name, clicking                on the column would cause the report view to be sorted                ascending by renter last name. If the USER would like to                reverse the sort order to descending, selecting the                column heading again would allow the report to be                resorted descending by renter last name.            -   The system will return the USER to Step 3 of the Basic                Flow on completion of this Alternative Flow, with the                report view resorted according to the USER request.        -   1.4.3.6 Add/Edit Custom View            -   At Step 3 of the Basic Flow, the USER will have the                ability to add or edit a custom report view. If the USER                selects to add a report view, the system will extend to                the RP-03 Add/Edit Custom View use case to define a new                custom report layout.            -   If the USER is viewing a custom report, they will have                the ability to edit the custom view by selecting an                ‘edit’ option. When a user requests to edit a custom                report layout, the system will extend to the RP-03                Add/Edit Custom View use case and pre-fill all                corresponding fields with the currently selected                parameters for the custom layout.            -   On completion of the use case extension, the USER will                be returned to Step 2 of Basic Flow in this use case and                be presented with the custom report layout that was                defined/modified.        -   1.4.3.7 Select Download Report            -   At Step 3 of the Basic Flow, the USER will have the                ability to download the current report view to a                comma-delimited file. If the USER selects to download a                comma-delimited version of the report, the system must                publish a comma-delimited file that includes all of the                data within the columns of the current report view. The                comma-delimited file should include column headings for                each of the columns of data provided to the USER. The                comma-delimited file must also include report header                information that includes:                -   Report View (open ticket detail/closed ticket                    detail)                -   Name of the Adjuster                -   Date and time the report was generated            -   The system should return the USER to the report view                (Step 3 of the Basic Flow) once a report has been                successfully downloaded.

1.5 Post-Conditions

-   -   If successful, a standard report is created for the USER.    -   If unsuccessful, the system state remains unchanged.

1.6 Special Requirements

-   -   The special requirements for this use case define all of the        personal report ‘views’ that are available to the USER. This        list of personal report views may be expanded at a later date to        include additional information from the ARMS/400 reporting        detail files, but only these views are anticipated for the        initial release.    -   1.6.1 Open Ticket Detail View        -   The Open Ticket Detail View provides the USER with columns            of data on all currently open tickets under their            management. The Open Ticket Detail report will display the            following information to the user:            -   1. Renter Name            -   2. Claim Number            -   3. Claim Type            -   4. Authorized Rate*            -   5. Authorized Days*            -   6. Rental Days*            -   7. Number of Days Behind*            -   8. Number of Extensions*            -   9. Surcharges (Y/N)            -   10. Authorized Amount*        -   Specific rules that must apply to the Open Ticket Detail            report view are outlined in the sections below;        -   1.6.1.1 Data Columns in the Open Ticket Detail View should            be presented in the order defined above. For example, renter            name belongs in column 1 of the Open Ticket Detail report.        -   1.6.1.2 All numeric fields should have averages provided at            the foot of each corresponding column. Numeric fields are            indicated with an asterisk (*) in the list above.        -   1.6.1.3 The default sort for the Open Ticket Detail view            must be by the Number of Days Behind field, with open            tickets that are the farthest behind presented at the top of            the list.        -   1.6.1.4 Any open tickets that have a value greater than            zero (0) in the Number of Days Behind field should be            highlighted to the USER.        -   1.6.1.5 The report must include a count of the total number            of contracts in the list.        -   1.6.1.6 The report view must include report header            information (in both screen and downloaded versions) that            includes:            -   the type/view of report (open ticket detail)            -   the name of the USER for whom the report was generated            -   the date/time the open ticket report was generated    -   1.6.2 Closed Ticket Detail View        -   The Closed Ticket Detail View provides the USER with columns            of data on closed ticket activity for the currently selected            date range (the default date range is the current plus            previous two (2) months). The Closed Ticket Detail report            will display the following information to the user:            -   1. Renter Name            -   2. Claim Number            -   3. Claim Type            -   4. Authorized Rate*            -   5. Authorized Days*            -   6. Billed Days*            -   7. Number of Extensions*            -   8. Total Charges*            -   9. Amount Received*            -   10. Billed Amount*        -   Specific rules that must apply to the Closed Ticket Detail            report view are outlined in the sections below;        -   1.6.2.1 Data Columns in the Closed Ticket Detail View should            be presented in the order defined above. For example, renter            name belongs in column 1 of the Closed Ticket Detail report.        -   1.6.2.2 All numeric fields should have averages provided at            the foot of each corresponding column. Numeric fields are            indicated with an asterisk (*) in the list above.        -   1.6.2.3 The default sort for the Closed Ticket Detail view            must be by the Claim Number field.        -   1.6.2.4 The report must include a count of the total number            of contracts in the list.        -   1.6.2.5 The report view must include report header            information (in both screen and downloaded versions) that            includes:            -   the type/view of report view (closed ticket detail)            -   the name of the USER for whom the report was generated            -   the date/time the open ticket was generated    -   1.6.3 Custom Report Views        -   The USER will have the ability to define their own custom            report views through the RP-03 Add/Edit Custom View use            case. These custom views are accessible from the Personal            Reporting module of ARMS Web.    -   1.6.4 Report View Management        -   The system will present all of the records in a report            result set on a single page, and the USER will scroll            through the results to find specific records. Report views            will not be presented in paging format (e.g., forcing the            USER to review the Next 25 of 427 records).

1.7 Extension Points

-   -   This section describes the extension points of this use case.    -   1.7.1 MA-13 Change Authorization        -   If the USER selects a line item from the Open Ticket Detail            report view, the USER will extend into the MA-13 Change            Authorization use case (see the Select Open Ticket from Open            Ticket Detail Report Alternative Flow on page 3 for            additional detail). The USER will have the ability to make            any changes or updates that their security level allows, and            have the opportunity to return to this use case without            making any changes to the open ticket. On completion of            activity in the MA-13 Change Authorization use case, the            USER will be returned to Step 3 of the Basic Flow within            this use case (be presented with the Open Ticket Detail            report).    -   1.7.2 RP-03 Add/Edit Custom View        -   If the USER selects to add or edit a custom view, the USER            will extend into the RP-03 Add/Edit Custom View use case            (see the Add/Edit Custom View Alternative Flow on page 4 for            additional detail). The USER will define or modify their            custom report layout and be returned to Step 2 of the Basic            Flow within this use case.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Personal Report Template Screen

-   -   This screen provides the template to build personal report        ‘views’, and supports Step 3 of the Basic Flow.    -   2.1.1 Screen Layout—see FIG. 146    -   2.1.2 Screen Field Definition

Screen Label Type Length Data Field Screen Specific Rule Office ComboBranch claims This combo list should include all of Box office theoffices for the currently active company that the USER is assigned to.If the value of this field is changed, the system should automaticallyrefresh the screen with the current report view for the newly selectedoffice. Handling for Output Handling for For personal reports, thisvalue Text should always be ‘Yourself’. Output <Report By> The <reportby> field is a place Text holder in the header of the report view. Forpersonal reports, this placeholder should be populated with the name ofthe user that is being reported on (i.e., the name of the user thatrequested the report). Output <Time/Date The <time/date stamp> field isa Text Stamp> placeholder in the header of the report view. For personalreports, this placeholder should be populated with the date and timethat the report was generated. Output <Report The <report type> field isa Text Type> placeholder in the header of the report view. For personalreports, this placeholder should be populated with the name of thecurrent report view (e.g., Open Ticket Detail, Custom View 1) <ColumnOutput <Data The data columns of the report Heading I Text Columns Ishould correspond to the data through X> through X> columns defined forthe selected report view (either static or custom report view). The datacolumns should be presented in the sequence that they are defined. TotalOutput Number of The total field should include the total Text Customernumber of contracts/customer files Files that are represented in thereport. Select a Combo Report view The ‘select a view’ combo box viewBox selection should include the names of all report views that areavailable to the user. This includes all pre-defined (e.g., Open TicketDetail) and user- defined custom views. There should be an additionaloption to ‘Add a custom view . . . ’. If selected, the system shouldredirect the user to the Add/Edit Custom View screen in the RP-03Add/Edit Custom View specification. Show Only Combo Claim Type The ‘showonly’ combo box should Box Filter include the following values: II ClaimTypes (default) nsured Claim Types laimant Claim Types ninsured ClaimTypes heft Claim Types When selected, the report should filter therecords to display in the requested report view according to theselection in this combo box. For example, if the selection in the ‘showonly’ field were ‘Insured Claim Types’, the report view would onlyinclude records that have a Claim Type of ‘Insured. From Combo Closedticket The ‘From’ combo box should box report from include all monthsand years for the date last 13 months (rolling 13 month period, currentmonth inclusive). For example a value in this field might include‘January 2000’. The default value should be 2 months prior to thecurrent month. To Combo Closed ticket The ‘From’ combo box should boxreport to date include all months and years for the last 13 months(rolling 13 month period, current month inclusive). For example a valuein this field might include ‘July 2000’. The default value should be thecurrent month.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Choose a different report            -   The ‘Choose a different report’ screen function provides                the USER with a hyperlink to the View a Different Report                section of the Personal Report Template screen. The                ‘Choose a different report’ screen function must be at                or near the header of the report.        -   2.1.3.2 Go to Report Averages            -   The ‘Go to Report Averages’ screen function provides the                USER with a hyperlink to the bottom of the report to                review the averages for each of the numeric columns in                the report view. The ‘Go to Report Averages’ hyperlink                must be at or near the header of the report.        -   2.1.3.3 Column Heading Sort            -   The ‘Column Heading Sort’ screen function allows the                USER to click on any column heading and have the current                report view sorted by the selected column. On initial                selection of a column heading, the system will resort                the report view by the column selected in ascending                order. If the sorted column is selected by the USER, the                system will resort the report in descending order.        -   2.1.3.4 Download this report            -   The ‘Download this Report’ screen function allows the                USER to click on a hyperlink and download a                comma-delimited copy of the current report view. The                downloaded copy must include:                -   Report Header Information                -    Name of the Report View                -    Name of the Person                -    Date and Time that the Report Was generated                -   Report View Column Headings                -   Report View Records        -   2.1.3.5 View Report            -   The ‘View Report’ screen function allows the USER to                submit a request for a different type and/or date range                of the report view. The system will refresh the screen                with updated report view information when this screen                function is invoked.        -   2.1.3.6 Edit Custom View            -   The Edit Custom View screen function is available only                in cases that the USER has a custom defined view active.                If the USER selects the Edit Custom View hyperlink, the                system will present the USER with the Add/Edit Custom                View screen and pre-populate the screen with the custom                view definition. This will allow the USER to edit the                custom views that they have previously defined.            -   See FIGS. 147( a)-(c).

Functional Design Specification Generate Management Report Version 1.11Generate Management Report 1. Generate Management Report 1.1 BriefDescription

-   -   This use case describes how a USER would request and generate        management reports using the on-line reporting functionality of        ARMS Web. On-line management reports provide real-time access to        open and closed ticket information, which provides the        management team of our customers with a tool to effectively        monitor rental management statistics. Using the on-line        reporting functionality, USERs can request and receive        summarized and detailed rental management reports on their        Office, on Adjusters within an office, or on the Repair        Facilities that are trading partners of a particular office.    -   NOTE: The on-line reporting functionality of ARMS Web provides        ARMS ticket data only. ARMS and Non-ARMS reporting is available        through the monthly L480 report.

1.2 Use Case Actors

-   -   All actors will use the use case to generate management reports        in the ARMS Web system. All of the following actors can be        defined generically as a USER:        -   ADJUSTER—Adjusters may be granted the authority to access            management reports in their user profile. (Users may be            granted access to management reporting capabilities through            their user profile, even if they are not considered            ‘managers’ in the ARMS Web system.)        -   COMPANY MANAGER—All users that are identified to the system            as managers will have access rights to the management            reporting functionality.    -   For the balance of this use case, all of the above actors will        be referred to as USER.

1.3 Pre-Conditions

-   -   The USER must be signed-on to the system.    -   The USER must have the authority to access management reports.

1.4 Flow of Events

-   -   The Flow of Events includes all the steps necessary to generate        management reports in the ARMS Web system.    -   1.4.1 Activity Diagram—see FIG. 148    -   1.4.2 Basic Flow        -   The Basic Flow of the Generate Management Report use case            includes all of the required activities for the USER to            successfully generate and view a management report using the            on-line reporting functionality in ARMS Web.        -   1. The USER selects to generate a management report from top            navigation.        -   2. The system generates a Closed Ticket Summary report by            Adjuster for the USER. Management reporting USERs will have            the ability to request additional summary or detail reports            for:            -   a. The office as a whole (by Office)            -   b. The adjusters within an office (by Adjuster)            -   c. The repair facilities doing business with a claims                office (by Repair Facility)        -   3. The system displays the report to the USER.        -   4. This ends this use case.    -   1.4.3 Alternative Flows        -   The Alternative Flows of this use case can occur when            certain conditions exist or when specific USER feedback is            provided.        -   1.4.3.1 Change Report View            -   At Step 6 of the Basic Flow, the USER will have the                ability to change the report ‘view’. (Report views are                covered in more detail in Section 1.6 Special                Requirements.) Report ‘views’ change the type of                information that is presented to the USER, but maintains                the same or similar scope.            -   If the USER selects to change the report view, the                system will return to Step 5 of the Basic Flow and                re-generate the report to build the requested view.                NOTE: The USER may also change the Report By criteria to                request a new report view (e.g., request a report by                Adjuster, Office, or Repair Facility).        -   1.4.3.2 Change Closed Ticket Date Range            -   At Step 6 of the Basic Flow, if the current report view                is a closed ticket report, the USER will have the                ability to change the date range of the report. The                available date range for closed ticket reporting will be                a rolling 13-month period (to be expanded to 24-months                in future releases) with the current month inclusive.                The default date range that will be presented to the                USER will be the current and previous two (2) months.                The USER will have the ability to select Month/Year to                begin and end the date range for the closed ticket                report. The USER will not have the ability to select                specific days within a month as part of the date range.            -   If the USER selects a new date range for the closed                ticket report view, the system will return to Step 5 of                the Basic Flow and re-generate the report to build the                USERs closed ticket report for the selected date range.            -   This applies to both summary and detail views of closed                ticket reports.        -   1.4.3.3 Select Summary Line Item from Open Ticket Summary            Report            -   At Step 6 of the Basic Flow, if the current report view                is an open ticket summary report, the USER will have the                ability to select a report line item, which will trigger                a request for a more detailed report for the selected                item. For example, if the current view were an Open                Ticket Summary for Adjusters within an office (Open                Summary by Adjuster), the USER would have the ability to                select an adjuster from the summarized report and review                the Open Ticket Detail report for that adjuster. This                ‘drill-down’ capability must be available for all report                types (by Office, by Adjuster, by Repair Facility).            -   If the USER selects a line item from a summary report                view, the system will return to Step 5 of the Basic Flow                and generate the Open Ticket Detail report view for the                selected item. From the Open Ticket Detail, the USER                will have the ability to return to the Open Ticket                Summary or to continue reviewing the Open Ticket Detail                report views for each adjuster/repair facility within                the office.        -   1.4.3.4 Select Open Ticket from Open Ticket Detail Report            -   At Step 6 of the Basic Flow, if the current report view                is an open ticket detail report, the USER will have the                ability to select a report line item to view the details                of the open ticket customer file. When selected, the                system will present the USER with the customer file that                corresponds to the selected open ticket. The USER will                be allowed to modify and submit changes to the customer                file (as proscribed in use case MA-13 Change                Authorization). Once activity on the customer file is                complete, the USER should be returned to the open ticket                detail report (Step 6 of the Basic Flow).        -   1.4.3.5 Select Summary Line Item from Closed Ticket Summary            Report            -   At Step 6 of the Basic Flow, if the current report view                is a closed ticket summary report, the USER will have                the ability to select a report line item, which will                trigger a request for a more detailed report for the                selected item. For example, if the current view were a                Closed Ticket Summary for Repair Facilities within an                office (Closed Summary by Repair Facility), the USER                would have the ability to select a repair facility name                from the summarized report and review the Closed Ticket                Detail report for that repair facility. This                ‘drill-down’ capability must be available for all report                types (by Office, by Adjuster, by Repair Facility).            -   If the USER selects a line item from a summary report                view, the system will return to Step 5 of the Basic Flow                and generate the Closed Ticket Detail report view for                the selected item. From the Closed Ticket Detail, the                USER will have the ability to return to the Closed                Ticket Summary or to continue reviewing the Closed                Ticket Detail report views for each adjuster/repair                facility within the office.        -   1.4.3.6 Select Closed Ticket from Closed Ticket Detail            Report            -   At Step 6 of the Basic Flow, if the current report view                is a closed ticket detail report, the USER will have the                ability to select a report line item to view the details                of the closed ticket customer file. When selected, the                system will present the USER with the closed customer                file that corresponds to the selected closed ticket. The                USER will be allowed to view/print the details of the                closed ticket, but will not have the ability to modify                or change the ticket information. From the closed                customer file, the USER will be returned to the closed                ticket detail report (Step 6 of the Basic Flow).        -   1.4.3.7 Sort Report            -   At Step 6 of the Basic Flow, the USER will have the                ability to select any report column heading to have the                report sorted by the selected column. If the USER                selects a column heading, the system must sort the                report by the selected column heading in ascending                order. The USER will have the ability to toggle between                ascending and descending sort order by re-selecting the                currently sorted column. For example, if the USER wanted                their report view to be sorted by Renter Name, clicking                on the column would cause the report view to be sorted                ascending by renter last name. If the USER would like to                reverse the sort order to descending, selecting the                column heading again would allow the report to be                resorted descending by renter last name.            -   The system will return the USER to Step 6 of the Basic                Flow on completion of this Alternative Flow, with the                report view resorted according to the USER request.        -   1.4.3.8 Add/Edit Custom View            -   At Step 6 of the Basic Flow, the USER will have the                ability to add or edit a custom report view. If the USER                selects to add a report view, the system will extend to                the RP-03 Add/Edit Custom View use case to define a new                custom report layout.            -   If the USER is viewing a custom report, they will have                the ability to edit the custom view by selecting an                ‘edit’ option. When a user requests to edit a custom                report layout, the system will extend to the RP-03                Add/Edit Custom View use case and pre-fill all                corresponding fields with the currently selected                parameters for the custom layout.            -   On completion of the use case extension, the USER will                be returned to Step 5 of Basic Flow in this use case and                be presented with the custom report layout that was                defined/modified.        -   1.4.3.9 Select Download Report            -   At Step 6 of the Basic Flow, the USER will have the                ability to download the current report view to a                comma-delimited file. If the USER selects to download a                comma-delimited version of the report, the system must                publish a comma-delimited file that includes all of the                data within the columns of the current report view. The                comma-delimited file should include column headings for                each of the columns of data provided to the USER. The                comma-delimited file must also include report header                information that includes:                -   Report View (open ticket detail/closed ticket                    detail)                -   Name of the Adjuster                -   Date and time the report was generated            -   The system should return the USER to the report view                (Step 6 of the Basic Flow) once a report has been                successfully downloaded.

1.5 Post-Conditions

-   -   If successful, a standard report is created for the USER.    -   If unsuccessful, the system state remains unchanged.

1.6 Special Requirements

-   -   The special requirements for this use case define all of the        management report ‘views’ that are available to the USER.        Management reports will be provided two USERs in two ways:        -   ‘Standard’ reporting views that have been defined by            Enterprise at the request of customers        -   ‘Custom’ reporting detail views that allow the USER to            define the columns of data that they would like to be            present in a report    -   1.6.1 Standard Management Reporting Views        -   Standard management reporting views are views that have been            defined by Enterprise based on the requests of customers.            These views will be carried forward in to ARMS Web and are            defined in this section.        -   The table below (see FIG. 149) includes the detailed data            fields that are available on each of the ‘standard’            management reports. The columns available in each report            have been expanded somewhat over the current state, as the            web environment offers more flexibility to provide            additional information than the current state green screen            application. The sequence of columns that must be presented            in each report are indicated using the number 1-10, with            fields that are on the screen but not in the primary data            table indicated with an ‘X’. For example, the first column            in the ‘Adjuster—Open Detail’ report is the renter name, the            second column is the claim number, etc.        -   1.6.1.1 All numeric fields should have averages provided at            the foot of each corresponding column. Numeric fields are            indicated with an asterisk (*) in the list above.        -   1.6.1.2 The default sort for the Open Ticket Detail views            must be by the Number of Days Behind field, with open            tickets that are the farthest behind presented at the top of            the list.        -   1.6.1.3 The default sort for the Closed Ticket Detail views            must be by Claim Number.        -   1.6.1.4 The default sort for the Open Ticket Summary views            must be by Adjuster Name (if by Adjuster), Repair Facility            Name (if by Repair Facility), or Office Name (if by Office)        -   1.6.1.5 The default sort for the Closed Ticket Summary views            must be by Adjuster Name (if by Adjuster), Repair Facility            Name (if by Repair Facility), or Month/Year (if by Office)        -   1.6.1.6 Any items in an Open Ticket Detail view that have a            value greater than zero (0) in the Number of Days Behind            field should be highlighted to the USER.        -   1.6.1.7 All report views must include a count of the total            number of contracts listed.        -   1.6.1.8 The report view must include report header            information (in both screen and downloaded versions) that            includes:            -   the type/name of the report view (e.g., open ticket                detail, open ticket summary)            -   the name of the entity that is being reported on. For                summary views, this should always be the office name.                For detail views, the entity name must be:                -   the adjuster name (for reports by Adjuster)                -   the office name (for reports by Office)                -   the repair facility name (for reports by Repair                    Facility)            -   the date/time the report was generated    -   1.6.2 Custom Management Reporting Views        -   Custom management reporting views allow the USER to define            the fields that they would like to use to build their own            report. The fields selected by the USER become the columns            of the report, and the system will not limit the number of            columns that a USER can request as part of the report.            Custom reporting views are discussed at length in use case            RP-03 Add/Edit Custom View.    -   1.6.3 Report View Management        -   The system will present all of the records in a report            result set on a single page, and the USER will scroll            through the results to find specific records. Report views            will not be presented in paging format (e.g., forcing the            USER to review the Next 25 of 427 records).

1.7 Extension Points

-   -   This section describes the extension points of this use case.    -   1.7.1 MA-13 Change Authorization        -   If the USER selects a line item from the Open Ticket Detail            report view, the USER will extend into the MA-13 Change            Authorization use case (see the Select Open Ticket from Open            Ticket Detail Report Alternative Flow on page 4 for            additional detail). The USER will have the ability to make            any changes or updates that their security level allows, and            have the opportunity to return to this use case without            making any changes to the open ticket. On completion of            activity in the MA-13 Change Authorization use case, the            USER will be returned to Step 6 of the Basic Flow within            this use case.    -   1.7.2 RP-03 Add/Edit Custom View        -   If the USER selects to add or edit a custom view, the USER            will extend into the RP-03 Add/Edit Custom View use case            (see the Add/Edit Custom View Alternative Flow on page 5 for            additional detail). The USER will define or modify their            custom report layout and be returned to Step 6 of the Basic            Flow within this use case.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Management Report View Template

-   -   This screen provides the USER with a management report view        template, and supports Step 6 of the Basic Flow.    -   2.1.1 Screen Layout—see FIG. 150    -   2.1.2 Screen Field Definition

Screen Label Type Length Data Field Screen Specific Rule Office ComboBranch claims This combo list should include all of Box office theoffices for the currently active company that the USER is assigned to.If the value of this field is changed, the system should automaticallyrefresh the screen with the current report view for the newly selectedoffice. Handling for Output Handling for For management reports, thisvalue Text should always be ‘Yourself’. Output <Report By> The <reportby> field is a placeholder Text in the header of the report view. Formanagement reports, this placeholder should be populated with the nameof the entity that is being reported on (i.e., Adjuster Name, OfficeName, or Repair Facility Name). Output <Time/Date The <time/date stamp>field is a Text Stamp> placeholder in the header of the report view. Formanagement reports, this placeholder should be populated with the dateand time that the report was generated. Output <Report The <report type>field is a Text Type> placeholder in the header of the report view. Formanagement reports, this placeholder should be populated with the nameof the current report view (e.g., Open Ticket Detail, Custom View 1)<Column Output <Data The data columns of the report Heading I TextColumns I should correspond to the data through X> through X> columnsdefined for the selected report view (either static or custom reportview). The data columns should be presented in the sequence that theyare defined. Total Output Number of The total field should include thetotal Text Customer number of contracts/customer files Files that arerepresented in the report. Go to Combo Report sorted The ‘Go to’ combobox should Box by navigation include all of the entities available inthe current report. For example, if the report were an Open TicketDetail view Reported By Adjuster, this list would include all of theAdjusters that would PAGE in the list. The ‘Go to’ combo box should onlybe available in detail views. Report by Combo Report sorted The ‘Reportby’ combo box should box by include all of the currently availablereport by options in the ARMS Web system. The report by options for theinitial release of ARMS Web 2.0 should be: ‘Office’, ‘Adjuster’, and‘Repair Facility’ Select a Combo Report view The ‘select a view’ combobox view box selection should include the names of all report views thatare available to the user. This includes all pre-defined (e.g., OpenTicket Detail) and user- defined custom views. There should be anadditional option to ‘Add a custom view . . . ’. If selected, the systemshould redirect the user to the Add/Edit Custom View screen in the RP-03Add/Edit Custom View specification. Show Only Combo Claim Type The ‘showonly’ combo box should box Filter include the following values: II ClaimTypes (default) nsured Claim Types laimant Claim Types ninsured ClaimTypes heft Claim Types When selected, the report should filter therecords to display in the requested report view according to theselection in this combo box. For example, if the selection in the ‘showonly’ field were ‘Insured Claim Types’, the report view would onlyinclude records that have a Claim Type of ‘Insured. From Combo Closedticket The ‘From’ combo box should box report from include all monthsand years for the date last 13 months (rolling 13 month period, currentmonth inclusive). For example a value in this field might include‘January 2000’. The default value should be 2 months prior to thecurrent month. To Combo Closed ticket The ‘From’ combo box should boxreport to date include all months and years for the last 13 months(rolling 13 month period, current month inclusive). For example a valuein this field might include ‘July 2000’. The default value should be thecurrent month.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Choose a different report            -   The ‘Choose a different report’ screen function provides                the USER with a hyperlink to the View a Different Report                section of the Personal Report Template screen. The                ‘Choose a different report’ screen function must be at                or near the header of the report.        -   2.1.3.2 Go to Report Averages            -   The ‘Go to Report Averages’ screen function provides the                USER with a hyperlink to the bottom of the report to                review the averages for each of the numeric columns in                the report view. The ‘Go to Report Averages’ hyperlink                must be at or near the header of the report.        -   2.1.3.3 Column Heading Sort            -   The ‘Column Heading Sort’ screen function allows the                USER to click on any column heading and have the current                report view sorted by the selected column. On initial                selection of a column heading, the system will resort                the report view by the column selected in ascending                order. If the sorted column is selected by the USER, the                system will resort the report in descending order.        -   2.1.3.4 Previous <Report By>            -   The ‘Previous <Report By>’ screen function allows the                USER to navigate to the previous detail record in a                particular detail report. For example, if the report                view were an Open Ticket Detail report by Repair                Facility, the ‘Previous <Report By> screen function                would allow the USER to move to the previous Repair                Facility detail record in a report. This screen function                should only be available on open or closed ticket detail                views (including custom views), and should only be                available if a previous report by item exists (i.e., we                wouldn't have a previous item if we were on the first                item in the list).        -   2.1.3.5 Next <Report By>            -   The ‘Next <Report By>’ screen function allows the USER                to navigate to the next detail record in a particular                detail report. For example, if the report view were an                Open Ticket Detail report by Adjuster, the ‘Next <Report                By> screen function would allow the USER to move forward                to the next Adjuster's detail report view within the                office. This screen function should only be available on                open or closed ticket detail views (including custom                views), and should only be available if a next report by                item exists (i.e., we wouldn't have a next item if we                were on the last item in the list).        -   2.1.3.6 Download this report            -   The ‘Download this Report’ screen function allows the                USER to click on a hyperlink and download a                comma-delimited copy of the current report view. The                downloaded copy must include:                -   Report Header Information                -    Name of the Report View                -    Name of the Person                -    Date and Time that the Report Was generated                -   Report View Column Headings                -   Report View Records        -   2.1.3.7 View Report            -   The ‘View Report’ screen function allows the USER to                submit a request for a different type and/or date range                of the report view. The system will refresh the screen                with updated report view information when this screen                function is invoked.        -   2.1.3.8 Edit Custom View            -   The Edit Custom View screen function is available only                in cases that the USER has a custom defined view active.                If the USER selects the Edit Custom View hyperlink, the                system will present the USER with the Add/Edit Custom                View screen and pre-populate the screen with the custom                view definition. This will allow the USER to edit the                custom views that they have previously defined.

Functional Design Specification Add/Edit Custom View Version 1.1Add/Edit Custom View 1. Generate Management Report 1.1 Brief Description

-   -   The Add/Edit Custom View use case describes the process to add        or edit a custom report view in the ARMS Web system. Custom        views allow the USER to select the data columns that they would        like to view in a report (from a pre-defined list of available        fields). USERs will have the ability to access their custom        views just as they would any other ‘standard’ report view.

1.2 Use Case Actors

-   -   All actors will use the use case to add or edit a custom report        view(s) in the ARMS Web system. All of the following actors can        be defined generically as a USER:        -   ADJUSTER        -   COMPANY MANAGER    -   For the balance of this use case, all of the above actors will        be referred to as USER.

1.3 Pre-Conditions

-   -   The USER must be signed-on to the system.    -   The USER must have the on-line reporting functionality active        (i.e., must be on an on-line reporting screen).

1.4 Flow of Events

-   -   The Flow of Events includes all the steps necessary to add or        edit a custom report view in the ARMS Web system.    -   1.4.1 Activity Diagram—see FIG. 151    -   1.4.2 Basic Flow        -   The Basic Flow of the Add/Edit Custom View use case includes            all of the required activities for the USER to successfully            add or edit a custom report view for use in the on-line            reporting functionality of ARMS Web.        -   1 The USER selects to add or edit a custom report view from            the on-line reporting screen(s).        -   2. The system displays a screen that allows the USER to            define or build a custom report view.        -   3. The USER defines the custom report view. The USER will            have the ability to indicate a Name for the view, and define            the data columns that they would like to have reported. The            comprehensive list of data columns that will be available to            the USER can be found in Section 1.6 Special Requirements            (on page 4).        -   4. The USER will submit the custom view to the system.        -   5. The system will update the ARMS Web database.        -   6. This ends this use case.    -   1.4.3 Alternative Flows        -   The Alternative Flows of this use case can occur when            certain conditions exist or when specific USER feedback is            provided.        -   1.4.3.1 Edit Custom Report View            -   At Step 1 of the Basic Flow, if the USER selected to                edit a current custom report view, the system will                present the screen to define/build a custom report and                pre-fill all fields with the current report definition.                For example, if the USER were editing their ‘Massive’                custom report view, ‘Massive’ would appear in the report                name field and all of the data columns that were                previously defined as the massive report would appear in                the ‘selected columns’ portion of the screen.

1.5 Post-Conditions

-   -   If successful, a custom report view is created for the USER.    -   If unsuccessful, the system state remains unchanged.

1.6 Special Requirements

-   -   The special requirements for this use case define all of the        management report ‘views’ that are available to the USER.        Management reports will be provided two USERs in two ways:    -   1.6.1 Custom Report Definition        -   This section provides the system framework for custom report            view definition in the ARMS Web system. These are additional            requirements around functionality to allow USERs to            define/build custom report views, and apply to the use case            as a whole.        -   1.6.1.1 USERs will have the ability to create one or more            custom views.        -   1.6.1.2 USERs will be able to define custom report views for            DETAIL views only (USERs will not have the ability to define            custom summary views). (Most of the numeric fields that can            be summarized for USERs are already provided in the standard            management report views.)        -   1.6.1.3 USERs will have the ability to select custom report            views by Office, by Adjuster, or by Repair Facility (similar            to the standard management reports).        -   1.6.1.4 Custom report views will be limited to the data            columns in the Custom Report View Data Domain (see 1.6.2            Custom Report View Data Domain)        -   1.6.1.5 Custom report views must define if the report view            retrieves Open, Closed, or All Ticket statuses.        -   1.6.1.6 All custom report views defined as ‘closed ticket            only’ must allow the user to indicate a date range. The            default date range for custom views will be the same as the            default range for standard closed ticket reports (the            current month plus two (2) prior months).        -   1.6.1.7 When a custom report view has been defined, the name            of the custom report view will become a selection from the            USERs view list. For example, ‘MyCustomView’ would be seen            in the list with ‘Open Ticket Detail’, ‘Closed Ticket            Detail’, etc.    -   1.6.2 Custom Report View Data Domain        -   The following is a list of all available data columns that a            USER may select as part of a custom report view. The number            of columns that a USER selects to make part of the custom            report view is not limited, which allows the USER to select            a subset or all of these data fields to be published in            their report.

Adjuster Claim Number Claim Type Office Name Renter Name State of RentalLocation Authorized Days Authorized Rate Policy Daily Rate Days BehindNumber of Policy Maximum Rate Extensions Rental Days Billed Days Billedto % Repair Facility Name Insured Name Rental Status Total ChargesBilled Amount Amount Received Other Charges Vehicle Condition AuthorizedTotal Amount (Driveable Flag/Repairable Flag) Surcharges Flag RentalStart Date Rental Close Date Termination Date Invoice Date InvoiceApprove Date Remittance Date Repair Facility Phone Number

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Add/Edit Custom View

-   -   This screen provides the USER with the ability to add or edit a        custom view, and supports Step 2 of the Basic Flow.    -   2.1.1 Screen Layout—see FIG. 152    -   2.1.2 Screen Field Definition

Screen Label Type Length Data Field Screen Specific Rule Name this TextCustom Report The name a USER provides to refer to report Name thecustom report view definition. The name of the report must be unique toother custom reports defined by the user (e.g., a single user can nothave two reports with the same name). This uniqueness must only beenforced at the user level (e.g., two different users CAN use the samename for a report). The name of the report will appear in the USERs‘Select a view’ combo box when the report view is saved. Start from aCombo Custom view The ‘Start from a View’ combo list View box startpoint allows a USER to select a default or ‘standard’ view as a startingpoint in report view definition. The values within the combo box shouldbe ‘Open Ticket Detail’ and ‘Closed Ticket Detail’. If selected, thesystem should use the values of the Report by ‘Adjuster’ standard reportto pre-populate the ‘New Report Fields’ list box. The default value ofthis field should be ‘-Select a Starting View-’ Ticket Combo Custom viewThe ‘Ticket Status’ combo box indicates Status box ticket status thescope of the report in terms of ticket status. The list should include‘Open Tickets’, ‘Closed Tickets’, and ‘All Tickets’. The system will usethis as part of the overall custom report definition. Available List BoxCustom view The ‘Available Fields’ list box includes Fields availablefields all of the fields that are available to be included in a customview, but have not yet been selected to be included in the report. Whenan available field is selected from the list to be included in thereport, the field should be removed from this list box (and populate the‘New Report Fields’ list box). For a list of all available fields seeSection 1.6.2 Custom Report View Data Domain above. New Report List BoxCustom view The ‘New Report Fields’ list box Fields selected fieldsincludes all of the fields that have been selected by the USER. Thesefields define the columns of the report. The sequence that the fieldsappear in the report is defined from top to bottom of this list box(e.g., the first field in the list = the first column in the report).This sequence can be modified using the Sequence Up and Sequence Downscreen functions (see 0 Screen Function Definition below). If the USERselects a starting view (from the Start from a View field), the list boxwill populate with all of the fields that make up the standard viewselected (e.g., if the USER selects ‘Closed Ticket Detail’ from theStart from a View field, all of the fields that make up a Closed TicketDetail report would populate in this field.

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Remove            -   The ‘Remove’ screen function allows a USER to remove                selected fields from the ‘New Report Fields’ list box                (and re-add them to the ‘Available Fields’ list box).        -   2.1.3.2 Insert            -   The ‘Insert’ screen function allows a USER to add                selected fields to the ‘New Report Fields’ list box (and                remove them from the ‘Available Fields’ list box).        -   2.1.3.3 Dictionary            -   The ‘Dictionary’ screen function allows a USER to open a                dictionary that defines all of the fields that can be                added to a report view. The dictionary will be included                as part of the help functionality of the system.        -   2.1.3.4 Sequence Up            -   The ‘Sequence Up’ screen function (presented with an                ‘up’ arrow in the screen shot) allows a USER to move a                selected field in the ‘New Report Fields’ list box up in                the sequence of the report.        -   2.1.3.5 Sequence Down            -   The ‘Sequence Down’ screen function (presented with a                ‘down’ arrow in the screen shot) allows a USER to move a                selected field in the ‘New Report Fields’ list box down                in the sequence of the report.        -   2.1.3.6 Save Report View            -   The ‘Save Report View’ screen function allows the USER                to save the custom report definition and return to the                reporting use case(s). The system will return the USER                to the report use case from which they entered this use                case (either RP-01 or RP-02) and be presented with the                newly defined report view.        -   2.1.3.7 Close without Saving            -   The ‘Close without Saving’ screen function allows the                USER to exist the screen with saving any changes made.                The system will return the USER to the report use case                from which they entered this use case (either RP-01 or                RP-02).        -   2.1.3.8 Delete            -   The ‘Delete’ screen function allows the USER to delete a                custom report view from their profile. When a custom                report view is deleted it should no longer be available                in the USERs view selection combo box. The system will                return the USER to the report use case from which they                entered this use case (either RP-01 or RP-02).

Functional Design Specification Maintain User Version 1.3 MaintainUser 1. Maintain User Use Case 1.1 Brief Description

-   -   The Maintain User use case describes how a USER would set up or        maintain a user in the ARMS Web system.

1.2 Use Case Actors

-   -   The following actors will interact with this use case:        -   ENTERPRISE ADMINISTRATOR—The ENTERPRISE ADMINISTRATOR is a            person who can perform this use case to set up any user in a            company.        -   COMPANY ADMINISTRATOR—The COMPANY ADMINISTRATOR is a person            who can perform this use case for the company. They may add            users and assign them to office(s) that they are the            administrator of within the company.        -   OFFICE ADMINISTRATOR—The OFFICE ADMINISTRATOR is a person            who can perform this use case for the company. The OFFICE            ADMINISTRATOR may maintain any user in their company            structure to which they have been assigned ownership.

1.3 Pre-Conditions

-   -   The USER must be logged into the system.    -   If maintaining a user, the USER should have the ability to        maintain that user. In order to maintain a user at a specific        office, the ADMINISTRATOR must have access to that specific        office.    -   If adding a user, the USER should have the ability to add a        user.

1.4 Flow of Events

-   -   The Flow of Events will include all the steps necessary to add        or maintain a company user in the ARMS Web system.    -   1.4.1 Activity Diagram—see FIG. 153    -   1.4.2 Basic Flow        -   The Basic Flow will describe how a USER will maintain a user            in the ARMS Web system.        -   1. The USER will choose to maintain user(s).        -   2. The system will present a list of all users that are in            all the offices the USER has access to maintain.        -   3. The USER will choose a user to maintain.        -   4. The system will display the user's information for the            USER to edit.        -   5. The USER will update the user's information and submit            the information to the system.        -   6. The system will validate the information entered.        -   7. The system will update the ARMS Web database.        -   8. This ends the use case.    -   1.4.3 Alternative Flows        -   1.4.3.1 Add User        -   At step three in the Basic Flow, the USER may choose to add            a user, if they have the authority level to do so. The USER            will enter a primary office, UserID, First Name and Last            Name for the new user. The system will then validate that            the office was entered and the UserID does not exist. If a            UserID match is found, or the office was not entered, the            system will display an error and request the USER enter a            new UserID. Otherwise, the system will display the default            settings for a new user; the USER will update the default            settings and submit the information to the system. The            system will validate the information entered, and update the            ARMS Web database. The use case is then complete.        -   1.4.3.2 Show All Users for the Company        -   At step three in the Basic Flow, the USER may choose to            display all users within the company. This would allow for            adding users to offices the USER controls. The USER will            choose the user they wish to work with and the system will            then display the user's information; the USER will add the            user to any offices the USER controls and submit the            information to the system. The system will validate the            information entered, and update the ARMS Web database. The            use case is then complete.            -   1.4.3.2.1 If a user's primary office is not an office                controlled by the USER, the USER may only add the user                to offices the USER controls. The USER should not be                able to change any of the user's settings. A USER that                has control of a user's primary office can only change                user settings.        -   1.4.3.3 User Information Validation Fails        -   In step six of the Basic Flow, the system may find that user            information entered by the USER does not meet the validation            criteria. The system should return the USER to step four of            the Basic Flow, show the USER the invalid data, and prompt            the USER to reenter the data.        -   This rule also applies for new user creation. Whenever a new            user is submitted to the system for creation, the system            must validate that the criteria entered is valid. If any            information is invalid, the system should present the            invalid date to the USER, and prompt the user to correct it.            -   1.4.3.3.1 The following fields must be populated to                complete a user update or new user creation.                -   Last Name                -   First Name                -   UserID (Must be validated to ensure it is not a                    duplicate ID)                -   Home Office (Must be a valid office and not null)        -   1.4.3.4 Cancel Add/Maintain User        -   Until step five in the Basic Flow, the USER may choose to            cancel the use case. The system should not store any changes            made by the USER within the use case.

1.5 Post-Conditions

-   -   If the use case was successful and the USER was maintaining a        user, the user criteria being changed will have been changed and        updated in the ARMS Web system.    -   If the use case was successful and the USER was adding a user,        the user will have been added in the ARMS Web system.    -   If the use case was unsuccessful, the system state will be        unchanged.

1.6 Special Requirements

-   -   1.6.1 User Inactivation        -   In order to inactivate a user, the following set of criteria            must be validated. If any of the criteria are found to be            true, then the system will not allow the USER to inactivate            the user.        -   If A4XREFL1/X4STCD is equal to ‘C’ (closed rental) and any            tickets were closed in the past seven days        -   If A4XREFL1/X4STCD is equal to ‘A’ (audited invoice)        -   If A4XREFL1/X4STCD is equal to ‘R’ (reservation)        -   If A4XREFL1/X4STCD is equal to ‘O’ (open contract)        -   If A4XREFL1/X4STCD is equal to ‘U’ (unconfirmed) and            A4XREFL1/X4RSFG is equal to ‘D’ (Direct Bill request)        -   If A4XREFL1/X4STCD is equal to ‘Z’ (sent) and            A4XREFL1/X4RSFG is equal to ‘C’ (extension request & message            sent)        -   If A4XREFL1/X4STCD is equal to ‘Z’ (sent) and            A4XREFL1/X4RSFG is equal to ‘M’ (authorization message sent)        -   If A4XREFL1/X4STCD is equal to ‘Z’ (sent) and            A4XREFL1/X4RSFG is equal to ‘X’ (extension request sent)        -   If A4XREFL1/X4STCD is equal to ‘B’ (authorized invoice) and            A4XREFL1/X4RSFG is equal to ‘B’ (invoice sent from ARMS)        -   If A4XREFL1/X4STCD is equal to ‘B’ (authorized invoice) and            A4XREFL1/X4RSFG is equal to ‘R’ (invoice returned to            adjuster)        -   If A4XREFL1/X4STCD is equal to ‘B’ (authorized invoice) and            A4XREFL1/X4RSFG is equal to ‘E’ (rejected system error)        -   If A4XREFL1/X4STCD is equal to ‘B’ (authorized invoice) and            A4XREFL1/X4RSFG is equal to ‘Q’ (rejected invoice ARMS            researching)    -   1.6.2 User Default Settings        -   Whenever a new user is created, the settings for that user            should be defaulted based on the user's primary office            profile settings. For example, if the office is a            reservation only office, the user should default to            reservation only. This does not imply that the administrator            cannot change the settings. This should also apply to            whether can receive work setting should be on or off for the            user/team. If all other users/teams in the office have the            setting either on or off, then the new user should mimic            this setting. Once again, this does not imply that the            administrator cannot change this setting.

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 Create or Modify User

-   -   This screen will allow the USER to search for and select a user        to modify or select to add a new user.    -   2.1.1 Screen Layout—see FIG. 154    -   2.1.2 Create or Modify User

Screen Specific Screen Label Type Size Screen Field Name Data Field NameRule New Team Radio 1 Create a New Team Button New User Radio 1 Create aNew User Button Indicator User ID: Input 10 User Id ARMS Profile IDFirst Name: Input 15 First Name of New First Name User Handling ForOutput 30 Handling For First Name + Last Name Last Name: Text Box 20Last Name of New Last Name User User ID Output 10 List of User Idswithin Adjustor Code the company Name Output 30 List of Users within aFirst Name + Last Company Name User ID: Input 10 User Id Adjustor CodePrimary office List Box 25 Primary office external organization namePrimary office Output 10 List of Primary offices external organizationabbreviated name Office Output 20 List of Office external organizationDescription Descriptions within name Company Office: Output 4 Office Idexternal organization abbreviated name

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 A-Z Anchor Links            -   When any of the letters are clicked, the list of users                should position itself with that letter presented at the                top of the user view area on the page.        -   2.3.3.2 Teams Link            -   When the team link is clicked, the list of teams should                position itself at the top of the view area on the page.                The list of teams should be placed last in the list of                all users/teams.        -   2.1.3.3 Process            -   When the Process button is clicked, the system should                check to see that the appropriate information was                entered in order to create a new user (Office, Last                Name, First Name UserID). If the information is entered,                the system will create a new user with those attributes                and the other user attributes defaulted. The system                should then display the new user's profile.

2.2 Create or Modify Team

-   -   This screen will allow the USER to input and change information        about a user (i.e. name, E-mail address, etc.)    -   2.2.1 Screen Layout—see FIG. 155    -   2.2.2 Create or Modify Team

Screen Specific Screen Label Type Size Screen Field Name Data Field NameRule New Team Radio 1 Create a New Team Button New User Radio 1 Create aNew User Button Indicator Name Output 20 Adjusters Associated FirstName + Last with the Company Name Handling For Output 20 Handling ForFirst Name + Last Name User ID Output 7 List of User Ids Adjustor CodeAssociated with a Company Primary office List Box 20 Primary officeexternal organization associated with abbreviated name Team Primaryoffice Output 10 List of Primary offices external organizationAssociated with a abbreviated name Company Office Output 20 List ofOffice external organization Description Descriptions name associatedwith a comp Office: Output 10 Office external organization abbreviatedname Team Name Input 15 Team Name external organization name

-   -   2.2.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.2.3.1 A-Z Anchor Links            -   When any of the letters are clicked, the list of users                should position itself with that letter presented at the                top of the user view area on the page.        -   2.2.3.2 Teams Link            -   When the team link is clicked, the list of teams should                position itself at the top of the view area on the page.                The list of teams should be placed last in the list of                all users/teams.        -   2.2.3.3 Process            -   When the Process button is clicked, the system should                check to see that the appropriate information was                entered in order to create a new team (Office, Team                Name). If the information is entered, the system will                create a new team with those attributes and the other                user attributes defaulted. The system should then                display the new team's profile.

2.3 User Profile

-   -   This screen will allow the USER to input and change information        about a user (i.e. name, E-mail address, etc.)    -   2.3.1 Screen Layout—see FIG. 156    -   2.3.2 User Profile

Screen Specific Screen Label Type Size Screen Field Name Data Field NameRule Reset Check Box 1 Reset Password Password Indicator Email Address:Text Box 15 Adjuster's Email e-Mail address Address First Name Text Box15 First Name First Name Handling For Output 10 Handling For FirstName + Last Name Last Name Text Box 10 Last Name Last Name User ID:Output 0 User Id Adjustor Code Active Check Box 1 User is Active Status:Active/Inactive Address Output 25 Home Office Address Customer AddressLine 1 + Customer Address Line 2 Phone: Output 10 Home Office PhoneCustomer Phone Number Number + Customer Phone Extension Postal Output 10Home Office Postal Zip Code Code City Output 15 Home Office Citycustomer city text ST/PROV Output 5 Home Office State customer statecode Office Output 10 Office external organization abbreviated name HomeOffice List Box 20 Office Name external organization name Other List Box20 Other authorized external organization authorized Offices for TheUser name Offices Allow files and Check Box 1 Allow files & actionprofile type value If Allow Files and action items to items to beassigned code Action Items have be assigned to to user been selected,this this user user or team will appear in the Handle For list.Authorize/ Check Box 1 Allow user to profile type value Extend RentalAuthorize/Extend code Rental User Check Box 1 Allow user to conductprofile type value Maintenance user maintenance code Create Check Box 1Allow user to create profile type value Reservation reservation codeReporting Check Box 1 Allow user to do profile type value (Management)reporting code Pay Invoice Check Box 1 Allow user to Pay profile typevalue Invoices code Days/Rental Text Box 10 Authorization Limit profiletype value on Days per Rental quantity $_max/ Text Box 10 AuthorizationLimit profile type value rental on Maximum Dollars amount per Rental

-   -   2.3.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.3.3.1 Process            -   When clicked, the system will ensure that all rules on                the page are enforced. Upon completion, the system will                return the USER to the Create a New User/Team page.            -   2.3.3.1.1 The user must have a First Name, Last Name and                Home Office entered. The Home Office must be a valid                office for that company.            -   2.3.3.1.2 Work Authority for each user will default to                all enabled.            -   2.3.3.1.3 If the Active switch has been set to inactive,                the system will check to see if the user owns any open                work. If the user owns work, the system will not allow                the user to be set to inactive. The system will notify                the USER that the user has open work assigned to them                and request that they transfer the work before                attempting to inactivate the user.            -   2.3.3.1.4 If the reset password option is set, the                system will reset the user's password. This will reset                the user's password to the password used for new users.                Need to verify what that password is.            -   2.3.3.1.5 If the File Ownership flag is turned off, the                system will check to see if the user owns any open work.                If the user owns work, the system will not allow the                file ownership flag to be turned off. The system will                notify the USER that the user has open work assigned to                them and request that they transfer the work before                attempting to turn off file ownership.

2.4 Team Profile

-   -   This screen will allow the USER to input and change information        about a user (i.e. name, E-mail address, etc.)    -   2.4.1 Screen Layout—see FIG. 157    -   2.4.2 Create or Modify Team

Screen Specific Screen Label Type Size Screen Field Name Data Field NameRule Allow files and Check Box 1 Allow action items to action items tobe assigned to team be assigned to this team Available List Box 30Available Members First Name + Last for Team Name E-mail Address TextBox 20 Email Address e-Mail address Handling For: Output 20 HandlingFor: First Name + Last Name Active Check Box 1 Team Active Status:Active/Inactive Indicator Team List Box 30 Team Members First Name +Last Members Name Phone Number Output 10 Branch Office Phone CustomerPhone Number Number + Customer Phone Extension Postal Output 10 BranchOffice Postal Zip Code Code Address Output 25 Home Office AddressCustomer Address Line 1 + Customer Address Line 2 ST/PROV Output 3Branch Office State customer state code or Province City Output 15 HomeOffice City customer city text Home Office Output 20 Home Office Nameexternal organization name Office Output 5 Office external organizationabbreviated name Team Name Text Box 20 Team Name external organizationname

-   -   2.4.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.4.3.1 Process            -   When clicked, the system will ensure that all rules on                the page are enforced. Upon completion, the system will                return the USER to the Create a New User/Team page.            -   2.4.3.1.1 The team must have a Team Name and Home Office                entered. The Home Office must be a valid office for that                company.            -   2.4.3.1.2 If the Active switch has been set to inactive,                the system will check to see if the team owns any open                work. If the team owns work, the system will not allow                the team to be set to inactive. The system will notify                the USER that the team has open work assigned to them                and request that they transfer the work before                attempting to inactivate the team.            -   2.4.3.1.3 If the File Ownership flag is turned off, the                system will check to see if the team owns any open work.                If the team owns work, the system will not allow the                file ownership flag to be turned off. The system will                notify the USER that the team has open work assigned to                them and request that they transfer the work before                attempting to turn off file ownership. If the user or                team does not receive File Ownership, that user or team                will not display in the Handle For list.

3. Application Operations

-   -   This section will detail all the application operations that are        part of this Functional Specification Document.        3.1 Build list of Users    -   (Office Id, First Name, Last Name, User ID)    -   Build a list of User first and last names NOT limited to a given        office in order to search for a user. Limited by the first or        last name passed.

3.2 Find User Information

-   -   (User Id)    -   Retrieve the current values for a user's profile.

3.3 Update User Information

-   -   (User Id, Name, e-mail Address, Out of Office, Handler for out        of office user, Initial Page, Is user Multi-company, Is User        Active, Current Password, New Password, Receive Authorization        Assignment)    -   Update the given data values for the user profile.        3.4 Build list of User offices    -   (User Id)    -   Build a list of office names for the offices the user is        assigned to.

3.5 Find User Office Information

-   -   (User Id, Office Id)    -   Retrieve the current values assigned for the user at a given        office.

3.6 Update User Office Information

-   -   (User Id, Office Id, and data values)    -   Update the given data values for the user profile.

3.7 Add User Office Information

-   -   (User Id, Office Id)    -   Assign user access to another office. Default values are set for        the users access.

3.8 Remove User Office Information

-   -   (User Id, Office Id)    -   Revoke assignment of the user to an office. The user cannot be        revoked from their primary office.        3.9 Build a list of users to which the administrator has access    -   (Company ID, Administrator ID, User ID)    -   Build a list of User first and last names limited to a given        office in order to maintain a user. Limited by the first or last        name passed.    -   3.10 Validate that User ID does not exist    -   (User ID)    -   Verify that the administrator must add a new user.

4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 User Language Preference        -   This is the user's language preference while working with            the ARMS Web System.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 10        -   Data Source: <Data Source>    -   4.1.2 Phone Number        -   This is the user's phone number.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 10        -   Data Source: <Data Source>    -   4.1.3 Profile Attribute Id        -   I.S. assigned identifier for a profile attribute. Must be            unique and non-blank. Each profilable item will have a            profile attribute.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 20        -   Data Source: <Data Source>    -   4.1.4 Last Name        -   This is the last name of the user.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 20        -   Data Source: <Data Source>    -   4.1.5 Handler for out of office user        -   This is the user who will handle work for the user who is            out of office.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 0        -   Data Source: <Data Source>    -   4.1.6 Start Page        -   This is the initial page that the user will see when he logs            on to the system.        -   Data Field Type: URL        -   Data Field Length: 256        -   Data Source: <Data Source>    -   4.1.7 Is user out of office?        -   This flag indicates that the user is out of office and no            work should be assigned to them. Instead another user can be            set up to handle for the user who is out of office.        -   Data Field Type: Boolean        -   Data Field Length: 1        -   Data Source: <Data Source>    -   4.1.8 Is the user multicompany?        -   This flag indicates that this user can do work for multiple            insurance companies. These are typically Enterprise            Rent-A-Car employees working on site at an insurance company            office or Rental Management Services employees who are also            Enterprise employees who manage rentals for the insurance            company but are not on site.        -   Data Field Type: Boolean        -   Data Field Length: 1        -   Data Source: <Data Source>    -   4.1.9 Can user receive work?        -   This flag indicates that user can receive work (e.g.            requests for authorization, requests for extension etc.).            Typically, a manager would set this flag to “No” so that            work would not be assigned to him or her although he or she            could be notified in certain situations like authority limit            exceeded etc.        -   Data Field Type: Boolean        -   Data Field Length: 1        -   Data Source: <Data Source>    -   4.1.10 Is User Active?        -   This flag indicates the user is currently active and may log            on to the system to do work.        -   Data Field Type: Boolean        -   Data Field Length: 1        -   Data Source: <Data Source>    -   4.1.11 Email Address        -   This is the email address of the user.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 30        -   Data Source: <Data Source>    -   4.1.12 First Name        -   This is the first name of the user.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 15        -   Data Source: <Data Source>    -   4.1.13 Password        -   This is the user specified password that the user will use            along with the user id to log on to the ARMS Web System.        -   Data Field Type: Password        -   Data Field Length: 10        -   Data Source: <Data Source>    -   4.1.14 User Id        -   This is the user id that the user will use to sign on to the            ARMS Web System. This id must be unique across the whole            system.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 10        -   Data Source: <Data Source>

5. Questions and Answers

-   -   Issue Number: 321    -   Question: When do we “Kill” profiles that have been created but        not used? Question 2—Do we allow for deleting users, and if so,        who would handle this function? Question 3—Do we allow for        deleting inactive user, and if so, who would handle this        function?    -   Status: Closed—Resolved    -   Resolution: 3-21-00, Dave Smith—The other questions would seem        to have procedures in place today. Unless there is a compelling        reason, I don't think we should reinvent the wheel. Could you        check with the ARMS team to find out?    -   08-07-00—Brad Reel: UserIDs that were created, but never        accessed will be made inactive after six months. UserIDs that        have not been accessed for two years will also be made inactive.        After being made inactive, they will be purged after three        additional months.    -   Issue Number: 322    -   Question: Do we allow for deleting users, and if so who would it        be that does so?    -   Status: Closed—Merged    -   Resolution: 3-21-00, Dave Smith—The other questions would seem        to have procedures in place today. Unless there is a compelling        reason, I don't think we should reinvent the wheel. Could you        check with the ARMS team to find out? 3-27-00, merged with Issue        321    -   Issue Number: 323    -   Question: When do we delete an inactive user? And who would        handle?    -   Status: Closed—Merged    -   Resolution: 3-21-00, Dave Smith—The other questions would seem        to have procedures in place today. Unless there is a compelling        reason, I don't think we should reinvent the wheel. Could you        check with the ARMS team to find out? 3-27-00, merged with issue        321    -   Issue Number: 324    -   Question: User ID: Do we have current Enterprise Business rules        that we need to enforce, and if so, what are they? The        assumption we made when discussing this was that the admin could        give them whatever ID the user desired. If user wanted the ID        Beavis, the admin could create it. The question is, are there        some rules we want to enforce (i.e. User ID's start w/first        three characters of insurance company's name, GEI for GEICO) and        some defaults for both UserID & Password? Maybe for GEICO, the        first user is GEI0001 and the default password is GEICO. Just        something we need to address.    -   Status: Closed—Resolved    -   Resolution: 3-22-00, Dave Smith—I think we should give them        whatever user ID they want.    -   3-30-00. Kim DeVallance—user ID is a company specific item. For        example, GEICO's is their associate ID (similar to our employee        number). Progressive uses their PACMAN ID, Nationwide uses their        RACF ID . . . all a similar concept. It is an ID that the        adjuster is familiar with and I think we should allow the        customer to use an employee number already familiar to the        adjuster.    -   4-7-00, Issue Mtg, the field is 10 characters, First three will        be company driven, the next 7 can be alpha/num and the users        choice.    -   4-11-00, Brad Reel—Current State, ID's are first three        characters of the company's name, and up to seven numeric        characters. Could possibly expand to seven alpha-numeric instead        of just numeric. Barring any disagreement, we will suggest the        following in the ARMS Web system: first three characters of the        company's name are the first three characters of the ID. Then        the ID must include at least 4 alpha-numeric characters with at        least one number in it. The minimum ID length would be 7        characters, the maximum 10. Suggest we try to force companies to        use their employee IDs as the seven digits. ARMS Web system can        generate a number if necessary.    -   Need to confirm with our security people that this is acceptable        security on an Enterprise-owned application. Also, should        consider whether or not we think first three characters of a        company's name will allow us to always uniquely identify        companies.    -   Issue Number: 325    -   Question: Current State we capture the primary address for the        user, (the address the user (adjuster) is located at) do we want        to do the same in future state? In the screen prototype should        the primary user (adjuster) address be capture in the user        profile screens, given that we currently have an office address        in the office profile?    -   Status: Closed—Resolved    -   Resolution: 3-30-00, Kim DeVallance—Kim—I do not think it is        necessary for the ARMS/Web application, but it may be a        mandatory field for the ARMS system when it processes info. I        would recommend checking with the analysts from ARMS. We pull        the address from ECARS when we send a paper bill, and if the        bill is electronic, the address does not matter.    -   4-7-00, Issue Mtg, Default to office address, allow at the user        level to be changed, if it is changed it will only update the        database not the 400.    -   4-11-00, Brad Reel—When creating a user, we need to capture a        user-specific address. It should default to the primary office        they are assigned to when they are first created, but be        changeable. This means we have to change the process for adding        a user so we identify their primary office before we enter        address information.    -   Issue Number: 326    -   Question: Can a user be maintained at more than one office? Do        we still have a default/primary office when the user is created?    -   Example: You have been created at the St. Louis Office and you        need to travel to California to help with a disaster, does        California have the rights to maintain you.    -   Status: Closed—Resolved    -   Resolution: 3-22-00, Dave Smith—For tracking purposes, I think        we need to maintain one profile only. If someone moves to        another location because of a disaster, we should move the        profile to that office. Perhaps to make it easy on the        transition, we could transfer their base profile and let the new        office modify accordingly.    -   3-27-00, Ask Brad to follow-up with Dave Smith.    -   3-30-00, Kim DeVallance—Current state, yes a user can be        maintained at more than one office, but a user should have a        primary office.    -   Issue Number: 327    -   Question: Do we need a primary office at which you see all work        below you? This would apply only to people who were in offices        that were not claims offices. Example: I am a regional VP        (wouldn't that be cool) and I want to use the system. I define        “Default One” as my region, so when I look at stuff in the        system an I see all the offices under my office as my default.    -   Status: Closed—Resolved    -   Resolution: 3-22-00, Dave Smith—Yes, I think this a good        enhancement.    -   3-30-00, Kim DeVallance—This would be great!!!    -   Issue Number: 328    -   Question: Do we need a primary office that you can create work        at? This would apply to everyone and defines the primary office        I can create work in. For an Adjuster, this would be their        primary office. For someone at a higher level, it would be the        office they assign work to if they create it. Following the        example above, if that VP creates a res (unlikely, but work with        me), this default would be the claims office it would be sent to        for completion.    -   Status: Closed—Resolved    -   Resolution: 3-22-00, Dave Smith—Yes, I think this a good        enhancement as well.    -   3-30-00, Kim DeVallance—Yes, but keep in mind during the life of        a rental we can transfer the rental to different offices within        the same company profile.    -   Issue Number: 329    -   Question: Where does the manager get assigned to a user? At the        Office Level, the User Level or the Team level? Can a user have        more than one manager?    -   Status: Closed—Resolved    -   Resolution: 08-08-00—Brad Reel: Upon further discussion with the        business, the process for selecting a person to handle an        authorization limit is as follows: When a user hits an        authorization limit, the system will request that the user        select another user to approve the request and handle the        rental. The system will only present users that have limits        higher than the requested amount/number of days. Once the user        has been selected, the rental will then be permanently        transferred to the chosen user.    -   Issue Number: 331    -   Question: Under Report Layout section, is this for the office to        give the user what fields that they want them to see? Then the        user can set how he views these fields in MY PROFILE?    -   Status: Closed—Resolved    -   Resolution: 3-21-00, Anita Klopfenstein—It allows the user to        create a default report layout as well as establish groupings.        For example: I may want a team group which allows me to select        adjusters to view. However, this would be a function which had        to be approved in the profile of the user. Otherwise they can        only see their work.    -   Issue Number: 332    -   Question: Are the authorization limits for the life of the        rental or the transaction, (as applied to use by an adjuster)    -   Status: Closed—Resolved    -   Resolution: 3-21-00, Anita Klopfenstein—Both—There is a daily        limit and a rental max. For the life of the rental.    -   Issue Number: 350    -   Question: Do we want to force a search before and admin can add        a user?    -   Status: Closed—Resolved    -   Resolution: 08-07-00—Brad Reel: When adding a user, the system        will search for the UserID and ensure it does not exist. No        other searches will be performed.    -   Issue Number: 352    -   Question: Where does the ability to change the language the user        can view the screens in reside? With the Admin or the user?    -   Status: Deferred    -   Resolution:    -   Issue Number: 356    -   Question: When setting up a user, should the office profile        restrict the user's profile? Or are the office and user profiles        independent of each other?    -   Status: Closed—Resolved    -   Resolution: 08-07-00—Brad Reel: Office profile overrides user        profile. A user can have more rights than the office, but will        still be restricted to only activities that can be performed in        that office based on the office profile while they are working        in that office.    -   Issue Number: 360    -   Question: Brad Decoder, Password/do we send e-mail to the admin        to let them know how many times login failed?    -   Status: I2 User Review    -   Resolution:    -   Issue Number: 365    -   Question: Do we need a batch process for adding users?    -   Status: Closed—Resolved    -   Resolution: 07-03-00—Brad Reel: This question has also been        asked in the more general setting of “Should a process exist for        walking a user through setting up an entire company (much like a        wizard tool).” For this release of ARMS Web (V2.0) a batch        process for creating users will not be created. There will also        not be a wizard for creating a company. However, for future        releases, this wizard will be a very worthwhile tool to create        and should be incorporated into future releases.

Functional Design Specification User Profile Version 1.0 1. User ProfileUse Case 1.1 Brief Description

-   -   The User Profile use case describes how the USER would customize        their working environment. User Profile will allow the USER to        change their password, set his or her out of office, and modify        their Favorite Locations list.

1.2 Use Case Actors

-   -   Actors will use this use case to update their user profile. The        following actors will interact with this use case:        -   ENTERPRISE ADMINISTRATOR        -   COMPANY ADMINISTRATOR        -   OFFICE ADMINISTRATOR        -   CLAIMS MANAGER        -   ADJUSTER        -   FIRST NOTICE OF LOSS ADJUSTER        -   PROCESSOR

1.3 Pre-Conditions

-   -   The company must be enrolled in ARMS Web.    -   The USER must be enrolled and have an active User ID and        password.    -   The USER must be logged into the ARMS Web system.

1.4 Flow of Events

-   -   The Flow of Events will include the necessary steps to make        changes and updates to “My Profile”.    -   1.4.1 Activity Diagram—see FIG. 158    -   1.4.2 Basic Flow        -   1. The USER will choose to edit their User Profile        -   2. The system will display the USER'S User Profile.        -   3. The USER will specify the action they would like to            perform (user settings, set out of office, add a Favorite            Location, remove a Favorite Location, edit a Favorite            Location).        -   4. The USER will select one of the options.        -   5. Based on the USER'S response, one or more of the            following subflows is executed:            -   If the USER chooses to edit a Favorite Location, the                Edit Favorite Location Subflow is executed.            -   If the USER chooses to add a Favorite Location, the Add                Favorite Location Subflow is executed.            -   If the USER chooses to remove a Favorite Location, the                Remove Favorite Location Subflow is executed.            -   If the USER chooses to set the Out of Office Function,                the Out of Office Subflow is executed.            -   If the USER chooses to Change Password, the Change                Password Subflow is executed.            -   If the USER chooses Confirmation Page, the Confirmation                Page Subflow is executed.        -   1.4.2.1 Edit Favorite Location Subflow            -   This subflow allows the USER to edit a location on their                Favorite Locations List.            -   1. The USER selects the location they wish to edit from                their Favorite Locations List.            -   2. The USER changes the name they wish to use to                identify the location. This is the name that will be                displayed to them in their Favorite Locations List.            -   3. The USER submits the information to the system.            -   4. The system updates ARMSWeb to reflect the new                Favorite Location.            -   5. The use case ends.        -   1.4.2.2 Add Favorite Location Subflow            -   This subflow allows the USER to add a location to the                Favorite Locations List.            -   1. The USER will execute Functional Specification MA-02:                Find a Rental Location to search for the location they                would like to add to their Favorite Locations List.            -   2. The USER selects the location they wish to add to                their Favorite Locations List.            -   3. The USER enters the name they wish to use to identify                the location. This is the name that will be displayed to                them in their Favorite Locations List.            -   4. The USER submits the information to the system.            -   5. The system updates ARMSWeb to reflect the new                Favorite Location.            -   6. The use case ends.        -   1.4.2.3 Remove Favorite Location Subflow            -   This subflow allows the USER to remove a location to the                Favorite Locations List.            -   1. The USER selects the location they wish to remove                from their Favorite Locations List.            -   2. The USER submits the information to the system.            -   3. The system updates ARMSWeb to reflect the removal of                the Favorite Location.            -   4. The use case ends.        -   1.4.2.4 Out of Office Subflow            -   This subflow allows the USER to select when they are out                of office and assigns their workload to another USER.            -   1. The USER will set choose to be Out of Office.            -   2. The USER will enter the beginning date of when they                will be Out of Office.            -   3. The USER will choose an alternate USER to handle                their work for each office the USER is assigned to.            -   4. The USER submits the information to the system.            -   5. The system validates the changes.            -   6. The system updates ARMSWeb database to reflect the                out of office status. At this time, the system will                assign any work that exists for the USER to the chosen                user(s). Any new work that is assigned to the USER will                automatically be reassigned by the system to the chosen                user(s).            -   7. The use case ends.        -   1.4.2.5 Change Password Subflow            -   This subflow allows the USER to change their current                password.            -   1. The USER enters the old password.            -   2. The USER enters the new password of their choice.            -   3. The USER re-enters new password for verification            -   4. The USER submits the passwords to the system.            -   5. The system validates the password changes.            -   6. The system updates ARMSWeb to reflect the new                password changes.            -   7. The use case ends.        -   1.4.2.6 Confirmation Page            -   This subflow allows the USER to turn on or off                confirmation pages in the ARMS Web system.            -   1. If Confirmation pages have been turned off, the user                will turn them on.            -   2. If Confirmation pages have been turned on, the user                will turn them off.            -   3. The USER submits the change to the system.            -   4. The system updates ARMSWeb to reflect the change.            -   5. The use case ends.    -   1.4.3 Alternative Flows        -   1.4.3.1 Invalid Password            -   At step five in the Change Password Subflow, if the                current password is incorrect or if the confirmed                password does not match the new password, the system                will prompt the USER to re-enter the old, the new and                the confirmation password.            -   1.4.3.1.1 It will be considered invalid if the new                password entered was one of the USER'S last five ARMS                Web passwords.            -   1.4.3.1.2 It will be considered invalid if the new                password is not at between six and 10 characters and                alphanumeric in type.—Validate 1.4.3.1.1 & 1.4.3.1.2 in                Sign-on.        -   1.4.3.2 Alternate Users not Chosen in Each Office USER is            Assigned            -   At step five in the Out of Office Subflow, the system                will validate that a user was selected to handle the                USER'S work in each office the USER is assigned to. If a                user was not chosen for each office, the system will                notify the USER that they must select a user to handle                their work in each office they are assigned to. The                system will then return the USER to step two of the Out                of Office Subflow.        -   1.4.3.3 Out of Office Start Date is in the Past            -   At step five in the Out of Office Subflow, the system                will validate that a user selected an out of office date                that is present (today) or in the future. If the date is                in the past, the system will generate an error and ask                the USER to enter a date that is either today or in the                future. The system will then return the USER to step two                of the Out of Office Subflow.        -   1.4.3.4 Favorite Location Name Entered is the same as an            Existing Location            -   When the USER submits the name for a new location, or                changes the name of an existing location, the system                will validate that the name entered is not an exact                duplicate of any other name in the USER'S list of                Favorite Locations. If the name is a duplicate, the                system will prompt the USER to enter a different name                for the location in question. The system will then                return the USER to step one of the Edit Favorite                Location Subflow.        -   1.4.3.5 Cancel User Profile            -   At any point during the use case up until a change has                been submitted to the system, the USER may decide to not                update their profile.

1.5 Post-Conditions

-   -   If the use case was successful then either a new password has        been assigned, the out of office function will be turned on, or        the USER'S Favorite Locations will be edited.    -   If the use case was unsuccessful then the system will remain        unchanged.

1.6 Special Requirements

-   -   None.

1.7 Extension Points

-   -   None.

2. Screen Design

-   -   A definition of the screen layout(s), screen data fields, and        screen functions that are used to implement the flows identified        above. More than one screen may be used to implement support for        the use case flow.

2.1 My Profile

-   -   This screen will allow the USER to pick which functions that        they wish to change.    -   2.1.1 Screen Layout—My Profile—see FIG. 159    -   2.1.2 My Profile

Screen Specific Screen Label Type Size Screen Field Name Data Field RuleRemove This Check Box 1 Delete branch from Branch preferred locationsindicator First Day Out: List Box 10 Out of office start Three dropdowns: date month, day, year Off Radio 1 Select feature setting ButtonOn Radio 1 Select feature setting Button Off Radio 1 Show confirmationButton page On Radio 1 Show confirmation Button page? Confirm Text Box 0Password change password N/A. Password: New Text Box 0 Password changepassword N/A. Password: Adjuster: List Box 30 Handler for out of FirstName + Last office user Name Handling For Output 15 Handling For FirstName + Last Adjuster Name Old Password: Text Box 0 Password User PaswdN/A. Address Output 30 Preferred Location Address Line + Address AddressLine2 Office Output 10 Claims Office external organization abbreviatedname Office: Output 10 Handler for out of external organization officeadjuster's abbreviated name office Name Input 30 Preferred Locationlocation name Defaults to address Name name

-   -   2.1.3 Screen Function Definition        -   This section includes the definitions for all functions that            can be performed within the screen. This includes operations            invoked by button clicks, specific shortcut keystrokes, or            other actor activity.        -   2.1.3.1 Process            -   When clicked, the system will validate the information                on the screen is correct and complete. If an error is                found the screen will be redisplayed with a message                indicating the error condition and highlighting the                field in error. If no errors are found, the database                will be updated with the new information.        -   2.1.3.2 Add A Different Office            -   When clicked, the system will take the USER to                MA-02-Find Rental Location Use Case. Here, the USER will                select a new location to add to the preferred location                list, and then return to the PR-07-User Profile Use                Case. The new information will be validated and the                database will be updated.

3. Application Operations

-   -   This section will detail all the application operations that are        part of this Functional Specification Document.

3.1 Retrieve User Profile

-   -   (User Id)    -   Retrieve user's current profile settings.

3.2 Update User Profile

-   -   (User Id, Out of Office, Assigned Adjuster, Start Page)    -   Update user's Out of Office status, Adjuster to handle work        during out of office period, and the user's initial page.

3.3 Change Password

-   -   (Current Password, New Password, New Password Confirmation)    -   Change the user's password from the current password to the new        password. Validate that the current password is correct.

4. Data Fields 4.1 Data Field Definition

-   -   This section includes a definition of all data fields included        in the functional specification.    -   4.1.1 Handler for out of office user        -   This is the user who will handle work for the user who is            out of office.        -   Data Field Type: Alpha-Numeric        -   Data Field Length: 0        -   Data Source: <Data Source>    -   4.1.2 Start Page        -   This is the initial page that the user will see when he logs            on to the system.        -   Data Field Type: URL        -   Data Field Length: 256        -   Data Source: <Data Source>    -   4.1.3 Is user out of office?        -   This flag indicates that the user is out of office and no            work should be assigned to them. Instead another user can be            set up to handle for the user who is out of office.        -   Data Field Type: Boolean        -   Data Field Length: 1        -   Data Source: <Data Source>    -   4.1.4 Password        -   This is the user specified password that the user will use            along with the user id to log on to the ARMS Web System.        -   Data Field Type: Password        -   Data Field Length: 10        -   Data Source: <Data Source>

5. Questions and Answers

-   -   Issue Number: 334    -   Question: Is out of office assigned at the user level or at the        office level? (Could you set this for each office you work out        of?) Example: You have been created at the St. Louis Office and        you need to travel to California to help with a disaster, does        California have the rights to maintain you.    -   Status: Closed—Resolved    -   Resolution: 4-7-00, Issue Mtd., Defer to user review I2    -   08-07-00—Brad Reel: A user will be required to set their out of        office function for all offices they are assigned to in order to        activate the function. The function is set up using the        assumption that a user would only be out of office if they were        unreachable at all offices (vacation, training, etc.). Since the        system can be accessed from any web connection, it is possible        for a user to do work for any and all offices they are assigned        to from anywhere. Therefore, it seems logical that a user would        only set their out of office function if they were not available        in any capacity.    -   Issue Number: 335    -   Question: Does a user have the field level control of the fields        he can see?    -   Status: Closed—Resolved    -   Resolution: 4-7-00, Issue Mtg., Should be set at the Office        level, the user should not be able to set the field that they        want to see.    -   4-11-00, Brad Reel—User does not need to have control over the        fields they see. Control at the office (or team level, where        applicable) is sufficient.    -   Issue Number: 336    -   Question: Are we still using the “Requests to be Processed” page        (the Command Center) as an option for a start up page?    -   Status: Future    -   Resolution: 4-7-00, Issue Mtg., Defer to future release, We are        not sure that it will not be an option, right now it is not.    -   4-11-00, Brad Reel—As of right now, the “Command Center” page        (Requests to be Processed) should not be an option for the start        page, and is not even planned for the ARMS Web system.    -   Issue Number: 434    -   Question: 07-06-00—Brad Reel: The ARMS Web redesign has a        requirement that the system would allow the user to choose the        page in the system they could use as their start-up page. Their        options were: the Command Center Page, the Action Items Page, or        the Create Reservation Page. Based on the way the system has        been designed to process since that time, it does not seem to        make sense to be able to choose anything other than the Action        Items page as a user's start page. The profile build team        suggests removing the option to allow a user to choose their        start page from the user profile.    -   07-07-00—Brad Reel: Feedback from the technical team and the        business suggests that it may make more sense to have Create        Reservation as an option, and have it process in a different        manner than the normal create reservation process. The main        advantage of this would be First Notice of Loss Adjusters. There        was also consensus that if the ability to select your start page        is removed in this release, it should be possible to easily add        it back in the future.    -   07-07-00—Brad Reel: Upon speaking to the database and build        teams, it should not be difficult to add the functionality back        to the system in a future release. A user's start page was set        up as an attribute of a user, and since there will still be        other attributes for a user, the start page will just be a new        attribute when it is added back. Therefore adding the ability to        choose a start page in a future release should not be difficult.    -   07-07-00—Brad Reel: This issue is being assigned to Sean        O'Donnell for review of the feasibility and impacts to the        create reservation process if a user is allowed to enter the        create res page without having entered the initial required        fields (i.e. Claim #, Claim Type, Renter Last Name, etc.). This        issue should be discussed for resolution at the 07-17 issues        meeting and is being assigned to Craig Lalumandier as resolution        contact until it is resolved. Upon resolution, this issue may        need to be assigned back to Brad Reel so that the decision can        be implemented into the user profile.    -   Status: Closed—Resolved    -   Resolution: Jul. 17, 2000 [Craig L.]—For the initial release,        the start page will not be profiled. This feature would not be        difficult to add in the future.    -   Sean O'Donnell 07-11-2000—I would NOT recommend allowing users        to have the create reservation page selected as their ‘Start        Page’ for the following reasons:        -   the reason(s) we split the reservation process into two            pages to begin with still exist 1) to have the information            to perform authorized and unauthorized matches to ensure            that the reservation that is being created does not already            exist, 2) to get the ‘where needed’ information to retrieve            a location & rates, 3) to get the claim type information up            front so that we can build the authorization section of the            create reservation page appropriately.        -   if we change the process to support ‘FNOL’ adjusters            differently than the ‘normal’ way of creating a reservation,            use of the application will be inconsistent.    -   Please contact me if there are concerns with these statements.

What is claimed is:
 1. A computer-implemented method for managing arental vehicle reservation for a replacement vehicle corresponding to adisabled vehicle, the method comprising: storing a transaction inmemory, the transaction corresponding to the replacement rental vehiclereservation, the replacement rental vehicle reservation having aplurality of operational activity phases, the operational activityphases comprising a reservation phase, an open rental phase and a closedrental phase; storing an administration schedule data structure inmemory, the administration schedule data structure configured to empowera plurality of different parties to perform management actions on thetransaction; communicating data over the Internet to a remote computeroperated by a party, the communicated data for populating a graphicaluser interface (GUI) screen for display on the remote computer, thecommunicated data comprising data about the transaction to facilitateperformance of a management action on the transaction; receiving aninput over the Internet from the remote computer through the GUI screen,the received input comprising an instruction from the party operatingthe remote computer to perform the facilitated management action on thetransaction; automatically performing the management actioncorresponding to the instruction on the transaction; conditioningperformance of the communicating step, the input receiving step, and theautomatically performing step on the party operating the remote computerbeing empowered by the administration schedule data structure to takethe facilitated management action on the transaction; and repeating thecommunicating step, the input receiving step, the automaticallyperforming step, and the conditioning step for a plurality of differentparties with respect to a plurality of different management actions overthe course of all of the operational activity phases for the rentalvehicle reservation; and wherein the method steps are performed by aprocessor.
 2. The method of claim 1 further comprising the processordefining the administration schedule data structure such that at least aplurality of the parties are empowered with differing authorities forperforming management actions on the transaction.
 3. The method of claim1 wherein the parties comprise a plurality of users who are employed bythe same business organization.
 4. The method of claim 3 wherein theusers comprise a plurality of insurance adjusters organized into avirtual workgroup through the administration schedule data structure. 5.The method of claim 1 wherein the parties correspond to a plurality ofdifferent business organizations.
 6. The method of claim 5 wherein theparties comprise a first party corresponding to an insurance company anda second party corresponding to a repair facility at which the disabledvehicle is undergoing repair work.
 7. The method of claim 6 wherein theadministration schedule data structure is further configured to empowerthe repair facility to create the replacement rental vehiclereservation.
 8. The method of claim 6 wherein the administrationschedule data structure is further configured to empower the repairfacility to extend an authorization period of the transaction.
 9. Themethod of claim 8 wherein the administration schedule data structure isfurther configured to empower the repair facility to extend anauthorization period of the transaction within a defined authorityrange.
 10. The method of claim 6 wherein the administration scheduledata structure is further configured to empower the repair facility toapprove an invoice for the transaction within a defined authority range.11. The method of claim 5 wherein the parties comprise a first partycorresponding to an insurance company and at least one second partycorresponding to at least one member of the group consisting of (1) anassist company, (2) a credit hire company, (3) a lawyer, and (4) a fleetmanagement company.
 12. The method of claim 1 wherein the transactioncomprises a plurality of the transactions, the method further comprisingthe processor performing the method steps for the plurality oftransactions, and wherein the parties comprise a plurality of differentinsurance companies and a plurality of different repair facilities. 13.The method of claim 12 further comprising the processor defining theadministration schedule data structure such that (1) at least one of theinsurance companies is associated with a plurality of different repairfacilities, and (2) at least two of the repair facilities associatedwith the at least one insurance company are differently empowered withrespect to the management actions they can perform on transactions forthe at least one insurance company.
 14. The method of claim 13 whereinthe different management actions eligible to be performed on thetransactions comprise (1) an authorization for a replacement rentalvehicle reservation during the reservation phase, (2) an authorizationchange for a replacement rental vehicle reservation during thereservation phase, (3) an authorization change for a replacement rentalvehicle reservation during the open rental phase, (4) an extension for areplacement rental vehicle reservation during the open rental phase, (5)a vehicle type change for a replacement rental vehicle reservationduring the open rental phase, (6) an invoice approval or rejection for areplacement rental vehicle reservation during the closed rental phase,and (7) an invoice remittance for a replacement rental vehiclereservation during the closed rental phase.
 15. The method of claim 12wherein the different management actions eligible to be performed on thetransactions comprise (1) an authorization for a replacement rentalvehicle reservation during the reservation phase, (2) an authorizationchange for a replacement rental vehicle reservation during thereservation phase, (3) an authorization change for a replacement rentalvehicle reservation during the open rental phase, (4) an extension for areplacement rental vehicle reservation during the open rental phase, (5)a vehicle type change for a replacement rental vehicle reservationduring the open rental phase, (6) an invoice approval or rejection for areplacement rental vehicle reservation during the closed rental phase,and (7) an invoice remittance for a replacement rental vehiclereservation during the closed rental phase.
 16. The method of claim 1further comprising: the processor storing the transaction in a masterdatabase of reservation data; the processor providing a synchingfunction so that a mobile computer may be selectively connected to themaster database and, under operator command, a database in the mobilecomputer containing reservation data may be uploaded to the masterdatabase; comparing the data from the two databases; and choosing tostore data from each according to a synch protocol at least partiallyspecified by a user.
 17. The method of claim 1 further comprising theprocessor permitting an entry of user satisfaction data and transmittingthe user satisfaction data to an authority for response thereto.
 18. Themethod of claim 1 further comprising the processor providing (1) a menuof action items with to a plurality of the transactions for selectiveentry and processing by a user thereof and (2) a command templatethrough which a user may execute a plurality of entered action items alltogether without further user action.
 19. The method of claim 1 furthercomprising the processor (1) performing the method steps with respect toa plurality of the transactions, the transactions corresponding to aplurality of replacement rental vehicle reservations with a plurality ofdifferent rental vehicle service providers, and (2) providing aplurality of graphical user interface (GUI) screens to a plurality ofthe remote computers over the Internet through a plurality of statelessconnections, the GUI screens configured to solicit user input forcreating and managing the transactions.
 20. The method of claim 1further comprising: the processor receiving vehicle repair data for thedisabled vehicle; and the processor automatically extending anauthorization period for the transaction based at least in part on thereceived vehicle repair data.
 21. An apparatus for managing a rentalvehicle reservation for a replacement vehicle corresponding to adisabled vehicle, the apparatus comprising: a processor forcommunicating with a remote computer over the Internet; and a memory,the memory configured to (1) store a transaction corresponding to thereplacement rental vehicle reservation, the replacement rental vehiclereservation having a plurality of operational activity phases, theoperational activity phases comprising a reservation phase, an openrental phase and a closed rental phase, and (2) store an administrationschedule data structure, the administration schedule data structureconfigured to empower a plurality of different parties to performmanagement actions on the transaction; wherein the processor and memoryare configured to (1) communicate data over the Internet to the remotecomputer, the communicated data for populating a graphical userinterface (GUI) screen for display on the remote computer, the remotecomputer being associated with a party, the communicated data comprisingdata about the transaction to facilitate performance of a managementaction on the transaction, (2) receive an input over the Internet fromthe remote computer through the GUI screen, the received inputcomprising an instruction to perform the facilitated management actionon the transaction, and (3) automatically perform the management actioncorresponding to the instruction on the transaction, wherein performanceby the processor of the communication operation, the input receivingoperation, and the automated management action performance operation isconditioned on the remote computer being associated with a party that isempowered by the administration schedule data structure to take thefacilitated management action on the transaction; and wherein theprocessor and memory are further configured to repeat the conditionalcommunication, input receiving, and automated management actionperformance operations for a plurality of different parties with respectto a plurality of different management actions over the course of all ofthe operational activity phases for the rental vehicle reservation. 22.The apparatus of claim 21 wherein the processor and memory are furtherconfigured to define the administration schedule data structure suchthat at least a plurality of the parties are empowered with differingauthorities for performing management actions on the transaction. 23.The apparatus of claim 21 wherein administration schedule data structureis further configured to define the parties such that the partiescomprise a plurality of users who are employed by the same businessorganization.
 24. The apparatus of claim 23 wherein administrationschedule data structure is further configured to define the users as aplurality of insurance adjusters organized into a virtual workgroup. 25.The apparatus of claim 21 wherein administration schedule data structureis further configured to define the parties such that the partiescorrespond to a plurality of different business organizations.
 26. Theapparatus of claim 25 wherein administration schedule data structure isfurther configured to define the parties such that the parties comprisea first party corresponding to an insurance company and a second partycorresponding to a repair facility at which the disabled vehicle isundergoing repair work.
 27. The apparatus of claim 26 wherein theadministration schedule data structure is further configured to empowerthe repair facility to create the replacement rental vehiclereservation.
 28. The apparatus of claim 26 wherein the administrationschedule data structure is further configured to empower the repairfacility to extend an authorization period of the transaction.
 29. Theapparatus of claim 28 wherein the administration schedule data structureis further configured to empower the repair facility to extend anauthorization period of the transaction within a defined authorityrange.
 30. The apparatus of claim 26 wherein the administration scheduledata structure is further configured to empower the repair facility toapprove an invoice for the transaction within a defined authority range.31. The apparatus of claim 25 wherein the parties comprise a first partycorresponding to an insurance company and at least one second partycorresponding to at least one member of the group consisting of (1) anassist company, (2) a credit hire company, (3) a lawyer, and (4) a fleetmanagement company.
 32. The apparatus of claim 21 wherein thetransaction comprises a plurality of the transactions, and wherein theprocessor and memory are further configured to perform the repeatedconditional communication, input receiving, and automated managementaction performance operations for the plurality of transactions, andwherein the parties comprise a plurality of different insurancecompanies and a plurality of different repair facilities.
 33. Theapparatus of claim 32 wherein the processor and memory are furtherconfigured to define the administration schedule data structure suchthat (1) at least one of the insurance companies is associated with aplurality of different repair facilities, and (2) at least two of therepair facilities associated with the at least one insurance company aredifferently empowered with respect to the management actions they canperform on transactions for the at least one insurance company.
 34. Theapparatus of claim 33 wherein the different management actions eligibleto be performed on the transactions comprise (1) an authorization for areplacement rental vehicle reservation during the reservation phase, (2)an authorization change for a replacement rental vehicle reservationduring the reservation phase, (3) an authorization change for areplacement rental vehicle reservation during the open rental phase, (4)an extension for a replacement rental vehicle reservation during theopen rental phase, (5) a vehicle type change for a replacement rentalvehicle reservation during the open rental phase, (6) an invoiceapproval or rejection for a replacement rental vehicle reservationduring the closed rental phase, and (7) an invoice remittance for areplacement rental vehicle reservation during the closed rental phase.35. The apparatus of claim 32 wherein the different management actionseligible to be performed on the transactions comprise (1) anauthorization for a replacement rental vehicle reservation during thereservation phase, (2) an authorization change for a replacement rentalvehicle reservation during the reservation phase, (3) an authorizationchange for a replacement rental vehicle reservation during the openrental phase, (4) an extension for a replacement rental vehiclereservation during the open rental phase, (5) a vehicle type change fora replacement rental vehicle reservation during the open rental phase,(6) an invoice approval or rejection for a replacement rental vehiclereservation during the closed rental phase, and (7) an invoiceremittance for a replacement rental vehicle reservation during theclosed rental phase.
 36. A computer-implemented method for managing areplacement rental vehicle reservation, the replacement rental vehiclereservation corresponding to a disabled vehicle, the method comprising:storing a transaction in memory, the transaction corresponding to thereplacement rental vehicle reservation, the replacement rental vehiclereservation having a plurality of operational activity phases, theoperational activity phases comprising a reservation phase, an openrental phase and a closed rental phase; storing an administrationschedule data structure in memory, the administration schedule datastructure configured to empower a plurality of different parties toperform management of the transaction; communicating data over theInternet to a remote computer, the communicated data for populating agraphical user interface (GUI) screen for display on the remotecomputer, the communicated data comprising data about the transaction tofacilitate performance of a management action on the transaction;receiving an input over the Internet from the remote computer throughthe GUI screen, the received input comprising an instruction forperforming the management action on the transaction; automaticallyperforming the management action corresponding to the instruction on thetransaction on a condition that a party from which the instruction inputwas received is empowered by the administration schedule data structureto perform the management action corresponding to the instruction;repeating the communicating step, the input receiving step, and theautomatically performing step over the course of all of the operationalactivity phases for the replacement rental vehicle reservation; andwherein the method steps are performed by a processor.
 37. The method ofclaim 36 further comprising the processor performing the communicatingstep and the input receiving step on a condition that a party associatedwith the remote computer is empowered by the administration scheduledata structure to perform the facilitated management action.